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Abstract 


This  document  describes  the  systematic  development  of  the  AFIT-sponsored  pro¬ 
gram  to  develop  a  laboratory-based  satellite  simulator.  The  simulation  satellite  (SIMS AT) 
system  supports  experimentation  in  areas  of  attitude  control,  precision  pointing,  and  vi¬ 
bration  suppression.  System  development  began  with  the  purchase  of  the  Tri-axis  Gas 
Bearing  from  Space  Electronics,  Inc.,  which  simulates  a  torque-free  space  environment  us¬ 
ing  a  low- friction  air  cushion.  Researchers  designed  SIMS  AT  subsystems  to  provide  power, 
attitude  control,  telemetry,  and  structural  support  to  experimental  payloads.  Project  chal¬ 
lenges  included  integration  of  attitude  control  software/hardware,  high-output  power  stor¬ 
age  devices,  remote  communications,  high-frequency  data  collection,  structural  design,  and 
user-interface  design. 


xxvm 


SIMS  AT:  A  SATELLITE  SYSTEM 
SIMULATOR  AND  EXPERIMENTAL 
TEST  BED  FOR  AIR  FORCE 
RESEARCH 


1.  Introduction 

1.1  Background 

In  recent  years,  the  U.S.  military  has  increasingly  realized  the  significance  of  space  as 
a  strategic  and  tactical  resource.  Satellite  imagery,  GPS-guided  munitions,  missile  warn¬ 
ing,  and  global  communications  for  deployed  forces  exemplify  the  importance  of  space 
assets  in  USAF  planning.  Recognizing  the  importance  of  space  resources,  the  USAF  has 
shifted  its  focus  from  being  strictly  an  “air  force”  to  becoming  the  premiere  “space  and  air 
force”  by  the  year  2025  [54].  Accordingly,  the  Air  Force  Institute  of  Technology  (AFIT) 
has  responded  by  developing  curriculum  and  conducting  research  to  support  space  opera¬ 
tions  and  cutting-edge  space  technologies.  Unfortunately,  much  of  the  space-related  work 
at  AFIT  has  been  limited  to  computer  simulation  or  stationary  laboratory  experiments 
due  to  a  lack  of  representative  space  hardware.  Consequently,  AFIT  desires  to  augment 
its  laboratory  facilities  with  a  more  realistic  space-platform  simulator.  Development  of  a 
satellite  simulator  would  allow  implementation  of  practical  experiments,  demonstration  of 
fundamental  motion  principles,  and  extension  of  Air  Force  research  capabilities.  Addition¬ 
ally,  a  satellite  simulator  would  provide  a  hands-on  learning  tool  to  enhance  the  educational 
experience  of  AFIT  students,  particularly  in  the  area  of  satellite  attitude  dynamics. 

To  initiate  the  development  process  of  a  satellite  simulator,  AFIT  purchased  a  Tri¬ 
axis  Air  Bearing  System  from  Space  Electronics,  Inc.  of  Berlin,  Connecticut.  The  system 
consists  of  an  air  bearing  (spherical  rotor,  hollow  shaft,  and  mounting  flanges),  a  pedestal, 
and  an  air  compressor.  Figure  1.1  shows  the  air  bearing  assembly.  Compressed  air  (at 
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approximately  75  psi)  flows  inside  the  pedestal  to  six  small  jets  in  the  air  bearing  cup; 
the  spherical  rotor  floats  above  the  cup  on  a  gas  film  that  is  less  than  0.0005  inch  thick. 
The  air  bearing  is  capable  of  360°  of  yaw  (rotation  about  the  vertical  axis),  360°  of  roll 
(rotation  about  the  horizontal  axis),  and  +/-300  of  pitch  (tilt  in  the  vertical  plane).  The 
air  bearing  can  support  objects  weighing  up  to  300  pounds  [53].  Although  not  capable 
of  independent  pitch,  roll,  or  yaw  motion  without  attached  components,  the  Tri-axis  Air 
Bearing  System  served  as  the  “backbone”  for  satellite  simulator  development. 


Figure  1.1  Air  Bearing  Assembly 

1.2  Design  Requirements 

With  the  Tri-axis  Air  Bearing  System  in  hand,  AFIT  faculty  tasked  the  1999  Grad¬ 
uate  Systems  Engineering  Team  to  develop  a  satellite  simulator  for  AFIT  use.  The  team’s 


charter  was  to  determine  the  customer  requirements  for  the  simulator,  design  a  system 
to  meet  those  requirements,  order  parts,  and  perform  as  much  of  the  system  integra¬ 
tion/implementation  as  possible.  As  with  any  other  development  effort,  this  process  began 
with  a  problem  to  be  solved  and  a  need  to  be  fulfilled.  To  provide  initial  focus,  the  design 
team  developed  a  “statement  of  need”  as  a  one-line  summary  of  the  problem  to  be  tackled 
in  the  design  effort: 

AFIT  needs  to  simulate  satellite  behavior  with  as  much  fidelity  as  possible. 

This  needs  statement  served  as  a  starting  point  from  which  the  design  team  devel¬ 
oped  more-detailed  design  requirements.  The  team  decided  to  name  their  overall  design 
effort  SIMS  AT —  the  SJMulation  SATellite.  The  first  meeting  allowed  the  team  to  “sit 
down  with  the  customers”  and  determine  additional  system  details.  The  customers  of  the 
simulator  (the  team’s  academic  advisors)  indicated  SIMS  AT  should  [32]: 

•  Support  research  and  educational  needs. 

-  Pure  and  “dual”  spin  experiments. 

-  3-axis  rigid  and  flexible  structure  experiments. 

—  Host  experimental  payloads. 

•  Be  simple  to  use. 

—  Meaningful  experiments  setup  and  run  by  one  researcher  and  one  technician  in 
less  than  a  week. 

-  Data  intuitively  displayed  in  real-time  and  easily  stored  for  future  replay  and 
analysis. 

•  Be  safe  -  as  required,  the  following  design  techniques  should  be  employed: 

—  Highly  reliable  and/or  redundant  critical  components. 

—  Containment  for  components  that  could  fail  catastrophically. 

•  Stay  within  budgetary  and  scheduling  constraints. 

—  Total  initial  costs  should  remain  under  $100K  (additional  funding  may  be  pos¬ 
sible,  but  will  add  to  total  development  time). 

-  The  system  should  be  ready  to  operate  by  FY  00. 
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1.3  Systems  Engineering  Approach 

1.3.1  Systems  Engineering  Framework.  Based  on  the  identified  top- 
level  needs,  it  was  clear  the  problem  was  multi-faceted.  Given  such  a  problem,  how  does  one 
simultaneously  evaluate  all  concerns  that  need  to  be  considered?  Given  several  alternative 
solutions,  how  is  the  “best”  alternative  selected?  How  can  one  make  sure  that  no  critical 
aspects  of  the  system  are  overlooked?  The  ability  to  find  answers  to  these  questions, 
and  others,  forms  the  foundation  of  the  field  known  as  systems  engineering.  As  an  initial 
step  in  the  design  of  AFIT’s  satellite  simulator,  the  design  team  researched  several  works 
on  the  theory  and  practice  of  systems  design  using  the  systems  engineering  approach. 
Study  in  the  systems  approach  gave  the  team  insight  into  multidiscipline  design  challenges, 
development  of  a  structured  problem-solving  methodology,  breakdown  of  lifecycle  phases, 
and  incorporation  of  systems  engineering  tools,  modeling  techniques,  and  decision  making 
methods. 

The  systems  approach  “represents  a  broad-based  systematic  approach  to  problems 
that  may  be  interdisciplinary.  It  is  particularly  useful  when  problems  are  complex  and 
affected  by  many  factors,  and  it  entails  the  creation  of  a  problem  model  that  corresponds 
as  closely  as  possible  in  some  sense  to  reality.  Its  usefulness  increases  with  problem  com¬ 
plexity  because  it  permits  the  engineer  to  take  a  broad  overall  view  of  the  problem  under 
consideration.  Thus  a  clearer  understanding  of  constraints,  alternatives,  and  consequences 
that  are  associated  with  the  problem  may  be  attained.”  [38:12]  This  summary  of  the 
systems  approach  clearly  shows  its  relevance  to  the  SIMS  AT  design  problem,  being  in¬ 
terdisciplinary  and  complex  in  nature.  This  theme  is  further  emphasized  by  Sage  as  he 
states,  “The  systems  engineering  approach  to  problem  solving  emphasizes  interactions  and 
interrelations  among  the  diverse  parts  of  a  problem.”  [49:r«] 

1.3.2  Systems  Engineering  Definition.  The  top-down,  interdisci¬ 
plinary,  and  iterative  aspects  of  systems  design  are  evident  in  the  following  systems  engi¬ 
neering  definitions: 
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“ Broadly  defined,  system  engineering  is  ‘ the  effective  application  of  scientific 
and  engineering  efforts  to  transform  an  operational  need  into  a  defined  system 
configuration  through  the  top-down  iterative  process  of  requirements  definition, 
functional  analysis,  synthesis,  optimization,  design,  test,  and  evaluation.  ’  The 
system  engineering  process,  in  its  evolving  of  functional  detail  and  design  re¬ 
quirements,  has  at  its  goal  the  achievement  of  the  proper  balance  between  oper¬ 
ational  ( i.e .,  performance),  economic,  and  logistics  factors.”  [8:12] 


“Systems  Engineering  is  an  interdisciplinary  approach  and  means  to  enable  the 
realization  of  successful  systems.  It  focuses  on  defining  customer  needs  and  re¬ 
quired  functionality  early  in  the  development  cycle,  documenting  requirements, 
then  proceeding  with  design  synthesis  and  system  validation  while  considering 
the  complete  problem:  operations,  performance,  test,  manufacturing,  cost  and 
schedule,  training  and  support,  and  disposal  Systems  Engineering  integrates 
all  the  disciplines  and  specialty  groups  into  a  team  effort  forming  a  structured 
development  process  that  proceeds  from  concept  to  production  to  operation.  Sys¬ 
tems  Engineering  considers  both  the  business  and  the  technical  needs  of  all  cus¬ 
tomers  with  the  goal  of  providing  a  quality  product  that  meets  the  user  needs.” 
(International  Council  on  Systems  Engineering)  [29] 

“Systems  engineers  are,  of  necessity,  technical  generalists.  Systems  engineer¬ 
ing...  is  not  intrinsically  mathematical.  Rather,  it  is  organizational,  judgmen¬ 
tal,  logical ,  goal- oriented,  and  admittedly  must  often  be  subjective [5:x] 


“Systems  engineering  is  the  systematic  application  of  proven  standards,  pro¬ 
cedures,  and  tools  to  the  technical  organization,  control,  and  establishment  of: 
system  requirements,  system  design,  system  management,  system  fabrication, 
system  integration,  system  testing,  and  system  logistics  support ”  [48:1-2] 


“Systems  engineering  is  a  branch  of  engineering  that  ’concentrates  on  the  design 
and  application  of  the  whole  as  distinct  from  the  parts ...  looking  at  a  problem  in 
its  entirety,  taking  into  account  all  the  facets  and  all  the  variables  and  relating 
the  social  to  the  technological  aspects .’  (Simon  Ramo  1973)”  [46:28] 

Based  on  the  previous  definitions  and  others,  the  design  team  formulated  its  own  systems 

engineering  definition  as  follows: 

“Systems  engineering  is  not  simply  another  engineering  discipline,  but  a  formal, 
multidisciplinary,  iterative  process  to  develop  customer  needs,  possible  solutions 
to  those  needs,  and  to  determine  which  alternatives  in  that  solution  space  would 
most  effectively  satisfy  the  customer.” 
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1.3.3  Systems  Architecting  vs.  Systems  Engineering.  What  is 
systems  architecting  and  how  does  it  differ  from  systems  engineering ?  As  described  pre¬ 
viously,  systems  engineering  encompasses  the  tools  and  methodology  necessary  to  move 
from  conceptualization  to  system  implementation,  with  emphasis  on  the  system  as  a  whole 
and  user  needs.  Indeed,  systems  architecting  is  also  concerned  with  these  same  issues,  and 
is  occasionally  used  interchangeably  with  systems  engineering.  However,  there  are  subtle, 
yet  significant,  differences  between  these  systematic  views  of  design. 

Webster’s  Dictionary  defines  architecture  as  “the  art  or  science  of  building.”  Tra¬ 
ditionally,  architecture  refers  to  the  planning  and  building  of  structures  related  to  civil, 
military,  or  naval  applications.  In  the  last  thirty  years  or  so,  the  term  has  been  applied  to 
technical  systems  with  increasing  regularity,  thus  the  common  use  of  the  terms  software  ar¬ 
chitecture,  computer  architecture,  and  the  like.  As  stated  by  Rechtin  [46:1],  “The  essence 
of  architecting  is  structuring.”  Thus,  the  essence  of  systems  architecting  is  structuring 
the  system  -  “to  bring  structure  in  the  form  of  systems  to  an  inherently  ill-structured 
unbounded  world  of  human  needs,  technology,  economics,  politics,  engineering,  and  in¬ 
dustrial  practice.”  [46:1]  Clearly,  this  definition  of  architecting  overlaps  that  of  systems 
engineering.  Rechtin  identifies  two  areas  in  which  distinctions  are  particularly  important 
-  function  versus  form  and  complexity  versus  specificity  [46:12]. 

The  guiding  principle  “form  follows  function”  is  basic  to  architecting,  which  focuses 
on  the  top-down  design  driven  by  function  as  opposed  to  form.  Hillaker  is  quoted  by 
Rechtin  as  stating  [46:12],  “System  engineering  is  form-based  and  system  architecting 
is  function-based.”  With  respect  to  complexity,  the  architect  is  “a  specialist  in  reducing 
complexity,  uncertainty  and  ambiguity  to  workable  concepts.  The  systems  engineer,  in 
contrast,  is  the  master  of  making  feasible  concepts  work.”  [46:13]  It  follows  that  systems 
architecting  “concentratefs]  on  concepts,  synthesis,  top-level  specifications,  nontechnical 
as  well  as  technical  interfaces,  and  mission  success”,  whereas  systems  engineering  “con¬ 
centrate^]  on  defined  subsystem  interfaces,  analysis,  and  performance  to  specification.” 
[46:13] 

The  architect’s  role  is  most  visible  in  the  early  stages  of  a  design,  when  concepts  are 
explored,  both  innovative  and  adaptive  in  nature.  Beam  describes  architecture  as  “a  matter 
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of  repetition  among  members  of  the  class,  and  often  repetition  within  a  single  member” 
[46:1],  illustrating  the  adaptive  nature  of  architecting,  wherein  functions  are  addressed 
by  exploring  how  other  systems  are  designed  regardless  of  their  form.  For  example,  a 
variable  geometry  wing  designed  to  provide  the  lift  function  for  an  aircraft  may  incorporate 
techniques  borrowed  from  biological  systems,  in  which  electrical  impulses  cause  muscle 
contractions.  Although  a  wing  and  a  human  muscle  are  very  different  in  form,  the  function 
of  altering  physical  characteristics  may  be  similar.  As  the  design  progresses,  the  visibility 
of  the  systems  engineer  increases,  as  the  proposed  concepts  are  refined,  detailed,  and 
implemented.  With  a  system  concept  already  suggested,  the  tools  of  systems  engineering 
can  most  efficiently  be  brought  to  bear. 

Why  are  the  distinctions  between  systems  architecting  and  systems  engineering  rel¬ 
evant  to  the  SIMS  AT  design?  This  design  progressed  from  initial  identification  of  needs 
and  concept  development,  through  the  actual  integration  of  subsystem  components,  ne¬ 
cessitating  an  understanding  of  both  systems  architecting  and  systems  engineering  tools 
and  techniques.  Thus,  the  team  performed  both  architecting  as  well  as  engineering  roles. 
The  line  between  these  roles  is  indeed  blurred,  as  the  “architect  hat”  and  “engineer  hat” 
are  sometimes  worn  simultaneously,  especially  during  concept  exploration  and  preliminary 
design.  Once  the  design  became  more  and  more  refined,  systems  engineering  tools  were 
more  readily  implemented. 

1.3.4  Systems  Engineering  Dimensions.  Hall  divides  the  systems 
engineering  approach  into  a  three-axis  morphological  box,  as  shown  in  Figure  1.2  [25]. 
The  time  dimension  of  systems  engineering  refers  to  the  system  lifecycle  -  the  sequences 
or  phases  that  extend  from  initial  conceptualization  through  system  retirement.  The  logic 
dimension  refers  to  the  problem-solving  process  -  the  steps  necessary  to  move  the  de¬ 
sign  from  one  lifecycle  phase  to  the  next.  Finally,  the  knowledge  dimension  refers  to  the 
specialized  knowledge  from  various  fields  necessary  to  address  and  solve  the  problems  at 
hand. 
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Figure  1.2  Systems  Engineering  Dimensions  [26] 

1.4  Systems  Engineering  Process 

1-4 -1  Problem- Solving  Methodology.  As  described  in  Section  1.3,  there 
is  an  underlying  process  in  a  well-planned  design  which  facilitates  the  evolution  of  the 
design  from  a  problem  statement  to  conceptual  alternative  solutions,  and  finally  to  a 
resultant  design  ready  for  implementation.  The  design  process  by  which  this  evolution 
occurs  can  be  a  considerable  design  problem  in  and  of  itself.  A  process  which  encumbers 
the  design  team  and  impedes  conceptual  evolution  is  not  desirable.  This  situation  can 
occur  when  a  process  is  too  rigid  for  the  problem  at  hand.  An  overly  rigid  process  can 
lead  to  overemphasis  of  process  objectives  at  the  expense  of  problem  objectives.  A  simple 
test  of  a  constraining  design  process  is  to  ask  whether  the  process  steps  are  significantly 
contributing  to  a  better  final  design.  If  process  steps  are  being  accomplished  for  their  own 
sake,  they  are  a  waste  of  the  design  team’s  time  and  the  client’s  resources.  Conversely, 
a  design  process  which  is  too  flexible  and  unstructured  provides  inadequate  methodology 
for  the  design  team  to  conceptualize  solutions,  compare  alternatives,  and  finally  choose  a 
“preferred”  system.  Existence  of  a  formal  process  can  be  a  significant  driver  in  keeping 
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the  design  team  on  track  and  providing  backbone  to  the  seemingly  unbounded  world  of 
systems  design.  Thus,  the  design  process  is  a  useful  tool  for  the  team  in  the  management 
of  complexity,  which  is  inherent  at  some  level  in  all  design.  The  question  therefore  arises, 
what  is  the  best  design  process  for  the  problem  at  hand? 

A  significant  objective  identified  by  the  customer  in  this  project  is  the  actual  opera¬ 
tion  of  the  satellite  simulator  system.  The  design  team  was  faced  with  a  complex  problem 
to  be  carried  from  the  conceptualization  stage  of  the  lifecycle  through  to  actual  integration 
(and  possible  operation)  of  the  system.  A  large  portion  of  the  system  lifecycle  develop¬ 
ment  needed  to  be  accomplished  in  a  relatively  short  amount  of  time.  The  design  team 
was  required  to  make  several  iterations  through  the  design  process  to  move  from  initial 
conceptualization  to  detailed  development.  A  flexible  design  process  was  used  to  handle 
this  schedule-driven  design  problem. 

The  approach  used  by  the  team  is  outlined  in  Sage  [50],  who  builds  from  the  seven 
step  process  identified  by  Hall  [25].  Table  1.1  illustrates  the  correspondence  of  the  Sage 
method  to  the  Hall  method. 


Table  1.1  Problem-Solving  Processes  of  Sage  vs.  Hall 


Sage 

Hall 

Issue  Formulation 

Problem  Definition 

Value  System  Design 

System  Synthesis 

Analysis 

System  Modeling 

System  Analysis 

Interpretation 

Decision-Making 

Implementation/Documentation 

The  key  to  Sage’s  structured  process  is  that  Hall’s  seven  steps  are  aggregated  into 
three  fundamental  steps:  issue  formulation,  analysis,  and  interpretation.  These  three  steps 
define  the  overall  system  design  process;  each  iteration  through  the  system  or  subsystem 
level  design  incorporates  these  steps.  The  tasks  within  each  fundamental  step  may  be  over- 
or  under-emphasized  as  necessary  depending  on  the  problem  or  subproblem.  Thus,  the 
design  team  is  not  encumbered  by  implementation  and  documentation  of  a  formal  seven- 
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step  process  for  every  problem  or  subproblem  encountered.  Sage’s  process  accommodates 
the  “time-to-market”  approach  which  may  require  less  emphasis  on  system  synthesis  and 
analysis  for  certain  subproblems  in  favor  of  requirements  satisfaction.  It  is  important  to 
note  that  although  the  process  appears  linear,  there  are  feedback  loops  within  every  step 
and  between  steps.  For  example,  during  analysis  it  may  be  discovered  that  a  significant 
objective  was  overlooked  earlier,  and  this  objective  may  then  be  incorporated  into  the 
value  system  design.  Moreover,  if  requirements  prove  to  be  very  difficult  or  costly  to  meet, 
they  should  be  challenged  and  the  problem  redefined. 

1-4 .2  Issue  Formulation.  As  a  starting  point  for  any  design  iteration, 
identification  of  problem  characteristics  and  relevant  issues  must  be  accomplished.  The 
following  information  should  be  considered  by  the  design  team  at  this  stage:  actors  involved 
the  design  process,  groups  affected  by  the  issues  or  proposed  solutions,  fields  of  knowledge 
required  to  solve  the  problem,  specific  needs  addressed  by  the  problem,  design  alterables, 
constraints  imposed,  and  cost  and  schedule  considerations.  The  problem  itself  is  isolated, 
quantified,  and  clarified.  The  system  (or  subsystem)  to  be  developed  is  delineated  from  its 
surrounding  environment.  This  abstraction  of  the  environment  consists  of  those  elements 
which  significantly  interact  or  affect  the  system  (or  subsystem),  but  are  beyond  the  design 
team’s  sphere  of  control  (at  this  stage).  Determination  of  what  is  the  system  and  what 
is  the  environment  allows  identification  and  classification  of  important  external  interfaces. 
These  tasks  correspond  to  Hall’s  “Problem  Definition”  step. 

Once  needs  are  identified,  development  of  system  objectives  begins.  This  process, 
Hall’s  “Value  System  Design”,  is  the  selection  of  a  set  of  objectives  that  will  guide  the 
search  for  alternatives  and  be  used  for  comparisons.  It  is  the  formalization  of  what  is 
important  to  the  customer.  Value  system  design  itself  can  vary  in  form.  For  some  problems 
or  subproblems,  value  system  design  may  be  the  enumeration  of  specific  measurables  by 
which  all  alternatives  will  be  judged.  Thus,  the  determination  of  a  preferred  solution  can  be 
accomplished  quantitatively.  At  a  top-level  systems  architecting  perspective,  it  is  highly 
desirable  to  create  an  objective  hierarchy  with  associated  measurables  to  comprise  the 
value  system  design;  these  measurables  will  be  weighted  in  the  end  to  select  a  preferred 


1-10 


alternative  x.  This  objective  hierarchy  approach  to  value  system  design  can  be  carried 
over  to  each  problem  or  subproblem  encountered  as  the  design  evolves  and  goes  through 
repeated  iterations  of  the  design  process.  In  some  instances,  a  formal  objective  hierarchy 
may  not  be  needed.  In  these  cases,  alternatives  which  are  feasible  (within  constraints) 
may  be  chosen  without  searching  for  the  preferred  alternative.  This  satisficing  approach 
may  be  desired  for  various  reasons:  tight  schedule  constraints  prevent  detailed  alternatives 
comparisons,  lack  of  reliable  modeling  data  prevents  accurate  comparisons,  or  the  utility 
of  a  preferred  solution  is  comparable  to  that  of  other  feasible  solutions. 

The  last  phase  of  issue  formulation  corresponds  to  Hall’s  “System  Synthesis”  step. 
A  set  of  alternative  solutions  is  developed,  through  research,  brainstorming,  reverse  engi¬ 
neering,  heuristics,  and  other  means.  These  alternatives  should  appear  feasible,  but  need 
not  fully  comply  with  constraints  at  this  stage  (later  investigation  could  reveal  a  feasible 
alternative  was  in  fact  infeasible;  or  conversely,  a  potentially  infeasible  solution  may  prove 
feasible).  Determination  of  these  alternatives  is  at  the  core  of  systems  architecting. 

1.^.3  Analysis *  Analysis  includes  the  necessary  system  modeling  and  evalu¬ 
ation  to  make  decisions  regarding  which  alternatives  to  pursue  further.  System  modeling  is 
the  development  of  means  to  evaluate  performance  of  each  alternative.  Models  are  system 
abstractions  used  to  evaluate  the  measurables  for  each  objective.  The  systems  evaluation 
phase  is  the  use  of  modeling  to  quantify  these  measurables.  At  this  stage,  alternatives  may 
be  refined  as  necessary  to  improve  performance. 

System  analysis  may  take  place  in  many  different  forms.  Construction  of  simula¬ 
tions,  itemization  of  costs,  development  of  prototypes,  and  engineering  estimates  are  just 
some  of  the  modeling  methods  available  to  the  design  team  to  quantify  performance  mea¬ 
surables.  The  goal  of  system  analysis  is  to  provide  data  for  the  decision  making  phase. 
Therefore,  modeling  is  only  necessary  to  the  level  of  fidelity  allowing  differentiation  of 
system  alternatives.  For  the  satellite  simulator  design  problem,  significant  use  of  mental 

depending  on  the  fidelity  necessary  to  make  sound  decisions,  an  objective  hierarchy  may  include  only 
qualitative  “values”.  These  values  represent  those  aspects  of  the  design  important  to  the  decision  maker. 
Qualitative  values  are  broken  down  into  quantitative  measurables  as  necessary  to  differentiate  and  rank 
alternative  designs. 
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modeling,  engineering  estimates,  and  research  allowed  quantification  of  measurables  to  a 
level  allowing  decisions  regarding  alternatives. 

1.4.4  Interpretation.  Interpretation  uses  the  information  gained  by  analy¬ 
sis  to  make  decisions  and  proceed  to  the  next  iteration  of  the  design  process.  In  the  decision 
making  phase,  an  alternative  (or  set  of  alternatives)  is  selected  based  on  the  analysis  data 
and  the  value  system  identified  earlier.  There  is  an  element  of  risk  and  uncertainty  in 
the  results  obtained  through  analysis,  and  these  uncertainties  must  be  considered  by  the 
decision  maker.  Dominated  solutions  should  be  identified  and  discarded  from  considera¬ 
tion.  Some  alternatives  may  be  better  in  certain  aspects,  but  less  preferred  in  other  areas. 
Decision  making  tools,  utility  theory,  and  objectives  weighting  are  needed  to  settle  on  a 
preferred  solution  set.  Interaction  with  the  customer  and  chief  decision  maker  is  critical 
during  this  stage. 

Once  this  set  of  alternatives  is  identified,  planning  for  action  is  necessary.  The 
design  process  to  this  point  should  be  communicated  and  documented.  Looking  ahead  to 
the  next  iteration,  the  allocation  of  resources  and  development  of  another  design  schedule 
is  performed.  The  design  process  then  begins  another  iteration,  in  which  the  problem 
is  recast  given  the  current  solution  set.  If  this  is  the  final  iteration,  the  final  design  is 
documented  and  implemented. 

1.4*5  Other  Problem-Solving  Methods.  One  major  advantage  of  Hall’s 
problem-solving  process  is  its  independence  from  the  lifecycle  phase.  The  iterative  process 
can  be  applied  at  each  stage  of  the  design.  Some  proposed  systems  engineering  processes 
overlap  the  problem-solving  and  lifecycle  phases  to  the  point  that  differentiating  between 
the  two  can  be  difficult,  and  the  iterative  nature  of  design  is  not  as  apparent.  The  “systems 
approach”  identified  by  Eisner  is  a  broad  overview  of  the  major  steps  necessary  to  develop 
a  system,  implicitly  defining  an  overlapping  problem-solving  process  and  design  lifecycle2. 
It  was  not  used  directly  in  the  SIMS  AT  design  due  to  the  single-dimensionality  of  the 

2Eisner  did  not  recommend  this  “systems  approach”  to  be  used  as  a  problem-solving  process  in  itself. 
In  fact,  the  seven-step  process  of  Hall  is  referenced  in  Eisner’s  work. 
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process3,  although  Eisner’s  work  provided  additional  systems  perspective  to  be  used  by 
the  team.  The  following  list  categorizes  the  steps  of  Eisner’s  “systems  approach”  [22:13- 
16]: 

1.  Needs  statement. 

2.  Goals  and  objectives. 

3.  System  requirements. 

4.  Specifications. 

5.  Synthesis  of  alternatives. 

6.  Analysis  of  alternatives. 

7.  Formulation  of  evaluation  criteria. 

8.  Update  of  specifications. 

9.  Building,  testing,  and  acceptance  of  system. 

10.  Documentation  and  installation. 

11.  Operation  of  system. 

12.  Modification  and  upgrade  of  system. 

Another  problem-solving  process  considered  by  the  team  was  proposed  by  Meredith, 
Wong,  Woodhead,  and  Wortman  [38:13-15].  The  process  is  similar  in  content  to  the  seven- 
step  process  of  Hall,  but  was  deemed  less  effective  than  Hall’s  process  for  use  in  the  SIMS  AT 
design.  This  six-step  process  is  compared  to  Hall’s  methodology  in  Table  1.2.  Specifically, 
the  design  team  favored  an  approach  in  which  the  synthesis  of  alternatives  preceded  the 
modeling  and  analysis  step.  Furthermore,  the  “allocate  resources”  step  in  this  proposed 
process  was  considered  extraneous  by  the  design  team  since  the  team  did  not  control  the 
allocation  of  resources  beyond  team  manpower.  Thus,  the  team  favored  Sage’s  aggregated 
problem-solving  process  based  on  Hall’s  steps. 


3The  single-dimensionality  of  this  “systems  approach”  refers  to  the  overlap  of  problem-solving  steps  and 
lifecycle  phases.  It  should  be  noted  that  Eisner  included  feedback  loops  and  iteration  within  his  “systems 
approach”  steps. 
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Table  1.2  Problem-Solving  Processes  of  Meredith,  et.  al.,  vs.  Hall 


Meredith,  et.  al. 

Hall 

Problem  Definition 

Problem  Definition 

Plan  Approach 

Value  System  Design 

Allocate  Resources 

System  Synthesis 

Model  and  Analyze 

System  Modeling 

Design  and  Evaluate  Alternatives 

System  Analysis 

Select  Preferred  Alternative 

Decision-Making 

Implementation/Documentation 

1.5  Design  Lifecycle  Description 

1.5.1  Lifecycle  Methodology.  The  use  of  an  appropriate  lifecycle  model 
as  part  of  the  systems  engineering  process  allows  the  design  to  be  effectively  managed  as 
it  progresses  from  a  concept  to  actual  implementation,  and  beyond.  As  with  the  formal 
problem-solving  process,  the  use  of  a  specified  systems  engineering  lifecycle  has  advantages 
and  disadvantages  when  compared  to  another  lifecycle  model.  Selection  of  an  appropriate 
lifecycle  model  at  the  outset  of  design  is  an  important  decision  which  guides  the  ensuing 
design  process.  Several  lifecycle  models  were  considered  for  use  in  the  SIMS  AT  design, 
with  eventual  selection  of  a  tailored  model  specific  to  this  design. 

1.5.2  Comparison  of  Various  Lifecycle  Models.  This  section  de¬ 
scribes  the  advantages  and  disadvantages  of  several  lifecycle  models  considered  for  use 
during  the  SIMS  AT  design. 

1.5. 2.1  Sage’s  Lifecycle  Model.  A  relatively  streamlined  lifecycle 
model  was  proposed  by  Sage  based  on  the  three  basic  phases  of  design  evolution  [50:32- 
33].  The  basic  phases  are  the  following  4: 


•  System  definition. 

•  System  design  and  development. 

•  System  operation  and  maintenance. 

4There  exist  feedback  loops  in  this  lifecycle  model  so  that  refinements  can  be  made  as  the  design  evolves. 
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The  activities  within  each  phase  of  the  three-phase  model  are  generally  obvious, 
but  may  be  explicitly  listed  for  larger  system  designs.  Sage  proposed  a  22-phase  model 
based  on  the  three-phase  model  to  be  used  for  large  systems  [50:33-39].  This  22-phase 
model  ensures  certain  objectives  and  design  decisions  are  met  before  moving  on  to  the  next 
phase,  thereby  acting  as  both  a  system  lifecycle  and  system  management  tool.  Both  the 
simplified  three-phase  model  and  expanded  22-phase  model  are  shown  in  Figure  1.3.  The 
advantage  of  Sage’s  simplified  model  is  clear:  it  is  easy  to  use  and  allows  flexibility.  The 
expanded  model  is  more  geared  for  large  military /industrial  projects  and  contains  steps 
not  applicable  to  this  design.  However,  the  simplified  model  had  drawbacks  with  respect  to 
the  SIMS  AT  design.  Aggregation  of  the  majority  of  the  design  decisions  into  one  “system 
design  and  development”  phase  made  the  natural  course  of  design  decisions  and  milestones 
less  clear.  This  lack  of  explicit  reference  to  the  stages  of  design  between  identification  of 
need  and  system  implementation  precluded  use  of  this  model  by  the  design  team. 

1.5. 2. 2  Hall’s  Lifecycle  Model.  Hall  proposed  a  seven-phase  system 
lifecycle  which  covered  the  entire  system  life,  to  include  system  phase-out.  Figure  1.4 
shows  how  Hall’s  phases  relate  to  those  of  Sage  [50:42].  The  individual  phases  of  Hall’s 
model  are  described  below  [25]: 

Program  planning.  This  phase  results  in  formulation  of  activities  and  projects  support¬ 
ive  of  the  overall  system  requirements.  The  system  management  plan  is  developed. 

Project  planning.  Purpose  is  to  configure  a  number  of  specific  projects  which  together 
comprise  the  overall  system  program. 

System  development.  This  phase  comprises  the  implementation  of  project  plans  through 
system  design,  resulting  in  preparation  of  architectures,  specifications,  diagrams,  and 
other  design  material. 

Production.  This  phase  includes  the  activities  necessary  to  physically  realize  the  system. 

Distribution.  This  phase  results  in  the  delivery  of  the  system  to  the  end  user. 

Operation.  The  ultimate  goal  of  the  system,  this  phase  comprises  use  by  the  customer, 
to  include  maintenance  and  retrofit  as  necessary. 
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Perception  of  Need 


Figure  1.3  Sage’s  Lifecycle  Model 

Retirement.  This  phase,  often  overlooked  in  early  planning,  includes  the  phase-out  and 
disposal  of  the  system. 

Although  a  comprehensive  model,  Hall’s  lifecycle  was  not  used  for  this  design  for  sev¬ 
eral  reasons.  Like  Sage’s  three-phase  model,  the  system  development  phase  of  Hall’s  model 
was  not  detailed  enough  to  provide  the  design  team  with  clear  direction  and  objectives  for 
this  project.  Furthermore,  the  system  was  designed  and  constructed  in  the  same  facility 
in  which  it  would  operate,  making  distribution  an  irrelevant  step.  As  for  the  operations 
and  retirement  phases,  they  were  not  directly  relevant  to  the  design  of  this  system,  and 
were  not  addressed  as  separate  lifecycle  phases  5. 

5As  needed,  continuation  of  the  current  design  team’s  efforts  through  system  retrofits  and  modifications 
was  accounted  for.  These  upgrade  programs  would  represent  separate  design  problems  and  possibly  separate 
thesis  work,  and  thus  were  not  included  in  the  team’s  lifecycle  model. 
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Figure  1.4  Lifecycle  Models  of  Hall  vs.  Sage 

1.5. 2. 3  Eisner’s  Lifecycle  Model.  Eisner  presented  a  lifecycle  model 
fairly  similar  to  that  of  Hall.  Despite  more  explicitly  referencing  concept  exploration,  this 
model  still  did  not  provide  the  design  stage  fidelity  desired  by  the  design  team.  Eisner’s 
lifecycle  consists  of  the  following  phases  [22:37-39]: 

•  Need  development. 

•  Concept  definition. 

•  Concept  validation. 

•  Engineering  development. 

•  Production. 

•  Operations. 
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1.5. 2-4  DoD  Lifecycle  Model.  The  Department  of  Defense  acquisition 
model  described  in  the  Defense  Acquisition  Deskbook  [13]  was  discounted  for  use  in  this 
design  due  to  its  relatively  rigid  review/milestone  structure.  As  with  the  previous  models 
discussed,  the  DoD  lifecycle  includes  phases  which  were  not  relevant  to  the  design  team’s 
academic  charter.  However,  the  DoD  model  provided  useful  guidance  as  to  the  delineation 
of  design  phases  and  use  of  design  reviews. 

1.5.3  SIMS  AT  Lifecycle  Model.  A  system  lifecycle  tailored  to  the 
SIMS  AT  project  was  chosen  to  represent  the  design  phases.  The  use  of  this  model  was 
driven  by  the  following  key  factors  used  by  the  design  team  in  their  lifecycle  modeling. 
The  lifecycle  should: 

•  Provide  clear  delineation  of  design  progression. 

•  Allow  natural  breaks  for  important  design  decisions. 

•  Include  only  relevant  lifecycle  phases. 

•  Adequately  accommodate  a  short  design  schedule. 

The  conceived  lifecycle  to  meet  these  needs  is  shown  in  Figure  1.5.  The  following  sections 
describe  these  lifecycle  phases  in  detail. 

1.5. 3.1  Concept  Exploration  and  Definition.  Once  a  need  has  been 
identified  and  initial  requirements  have  been  defined,  the  system  design  process  enters  the 
first  stage  of  the  system  lifecycle.  This  phase  includes  refinement  of  system  requirements, 
along  with  exploration  of  various  concepts  which  can  be  designed  to  meet  identified  re¬ 
quirements.  Emphasis  is  on  top-level  system  architectures,  with  detailed  design  decisions 
avoided  at  this  point.  The  focus  of  this  lifecycle  phase  is  to  identify  and  differentiate  broad 
solution  classes.  Through  initial  modeling,  research,  trade  studies,  and  decision  maker 
inputs,  a  class  (or  classes)  of  solutions  may  be  identified  which  stands  out  from  the  rest. 
This  solution  class  (or  classes)  can  then  be  further  refined  and  investigated  during  the  next 
lifecycle  phase. 
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Figure  1.5  SIMS  A  T  L  i  recycle  Model 

1.5. 3. 2  Preliminary  Design.  In  this  lifecycle  phase,  the  solution 
class  (es)  identified  in  Concept  Exploration  and  Definition  is  (are)  further  refined.  Sub¬ 
system  level  requirements  are  defined  in  this  phase.  Trade  studies,  research,  and  system 
modeling  are  used  to  determine  which  types  of  subsystems  best  meet  the  cost-effectiveness 
system  goals.  The  output  of  this  phase  includes  a  system  architecture  complete  with  iden¬ 
tified  subsystem  types,  along  with  subsystem  requirements  and  interface  identification.  In 
short,  this  phase  translates  system  solution  classes  into  subsystem  solution  classes,  which 
are  further  defined  and  integrated  in  the  next  lifecycle  phase. 

1.5. 3. 3  Detailed  Design.  The  subsystems  are  further  designed  in  this 
phase.  Detailed  trade  studies  should  be  used  to  determine  the  exact  subsystem  architec¬ 
tures  which  make  up  the  overall  system.  Integration  and  interface  issues  are  resolved  in 
this  phase  and  the  overall  system  is  completely  defined  at  this  point,  subject  to  change  as 
system  test  and  evaluation  may  require.  The  product  of  this  lifecycle  phase  is  a  detailed 
functional  system  architecture  with  subsystems  designed  and  integrated. 
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1.5. 3. 4  Final  Design.  The  final  product  is  described  and  documented 
for  future  users  in  this  phase.  Unresolved  design  issues  are  discussed.  The  design  team 
makes  recommendations  and  draws  conclusions  to  aid  future  users  and  designers. 

1.6  Document  Format 

The  remainder  of  this  document  is  structured  to  match  the  design  activity  shown  in 
Figure  1.6.  The  following  chapters  correspond  directly  to  each  lifecycle  phase.  Within  each 
chapter,  the  problem-solving  process  is  described,  with  successive  iterations  within  a  phase 
detailed  as  necessary.  Thus,  each  chapter  documents  the  issue  formulation,  analysis,  and 
interpretation  activities  relevant  to  the  respective  lifecycle  phase.  Background  information 
on  design  decisions,  applied  theory,  software  development,  and  other  pertinent  areas  is 
supplied  in  the  appendices. 


FINAL  DESIGN 


Figure  1.6  SIMS  AT  Summary  of  Design  Activity 
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II.  Concept  Exploration  and  Definition 

2. 1  Overview 

Once  a  need  has  been  identified  and  initial  requirements  have  been  defined,  the  sys¬ 
tem  design  process  entered  the  first  stage  of  the  system  lifecycle.  This  phase  included 
a  formal  definition  of  the  user’s  needs  and  requirements,  followed  by  an  exploration  into 
various  concepts  which  can  be  designed  to  meet  the  identified  requirements.  To  effectively 
manage  the  problem  complexity,  emphasis  in  this  phase  was  on  top-level  system  architec¬ 
ture  issues,  with  detailed  design  decisions  left  for  future  phases.  The  focus  of  this  lifecycle 
phase  was  to  identify  and  differentiate  broad  solution  classes.  Through  initial  modeling, 
research,  trade  studies,  and  decision  maker  inputs,  classes  of  solutions  were  identified  which 
stand  out  from  the  rest.  These  solution  classes  can  then  be  further  refined  and  investigated 
in  the  next  lifecycle  phase.  The  waterfall  design  model  in  Figure  2.1  highlights  the  focus 
of  this  chapter. 


Figure  2.1  Concept  Exploration  and  Definition  Design  Activity 
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2.2  Issue  Formulation 


2.2. 1  Problem  Statement.  As  a  first  step  in  the  design  process,  a  problem 
statement  should  be  developed  which  captures  the  goals  of  the  design  in  a  clear  and  concise 
manner.  The  scope  of  this  satellite  simulator  design  was  narrowed  such  that  the  needs  of 
the  direct  customers  were  the  primary  design  drivers,  with  the  capability  to  meet  outside 
agency  needs  retained,  but  not  of  primary  concern.  The  problem  statement  was  refined  as 
follows: 

Design  a  satellite  system  simulator  for  use  as  an  experimental  testbed  for  Air  Force 
Institute  of  Technology  (AFIT)  and  other  Air  Force/D oD  research,  and  provide  an  instruc¬ 
tion  aid  to  AFIT  instructors  teaching  satellite  dynamics  and  control. 

2.2.2  Problem  Scope.  The  design  study  focused  on  developing  a  satellite 
simulator  platform,  and  integrating  the  testbed  hardware  with  a  computer-based  control 
system,  hereafter  referred  to  as  the  “ground  station” .  The  ground  station  must  be  capable 
of  sending  commands  to  and  receiving  data  from  the  platform-based  portion  of  the  system, 
hereafter  referred  to  as  the  “satellite”.  In  addition,  the  ground  station  must  support  the 
development  of  the  system  control  laws  (including  simulation  of  the  proposed  laws  prior 
to  actual  satellite  operation),  provide  a  graphical  representation  of  system  controls  and 
the  satellite  response  to  commands,  and  allow  for  collection  and  replay  of  satellite  motion 
and  experimental  telemetry.  The  SIMS  AT  design  should  be  robust  such  that  a  variety 
of  experiments  can  be  accomplished  with  minimal  adjustments.  Some  experimental  ar¬ 
eas  identified  included  investigation  of  control-moment  gyros,  optimal  flywheel  orientation 
design,  flexible  space  structures  behavior  and  vibration  control,  satellite  attitude  and  track¬ 
ing  control,  and  ground  station  simulation  of  the  satellite  (including  hardware-in-the-loop 
simulations,  in-class  presentations,  and  technology  demonstrations).  The  project  goal  was 
to  implement  an  operational  SIMSAT  design  by  March  1999. 

This  first  iteration  through  the  design  process  focused  on  refining  requirements  and 
exploration  of  concepts,  and  was  not  intended  to  result  in  design,  implementation,  or 
evaluation  of  an  actual  system.  The  goal  of  this  phase  was  to  understand  the  problem, 
gain  knowledge  in  areas  needed  to  attack  the  problem,  develop  objectives  and  enumerate 


2-2 


constraints,  and  then  identify  possible  classes  of  solutions  based  on  cost,  performance,  and 
other  relevant  criteria.  This  identification  provided  inputs  into  the  Preliminary  Design 
phase.  This  first  iteration  was  completed  by  the  end  of  June  1998. 

2.2.3  Relevant  Disciplines.  The  design  team  identified  the  following  dis¬ 
ciplines  as  relevant  to  solving  this  problem,  incorporating  knowledge  from  these  disciplines 
as  needed.  These  disciplines  represent  the  knowledge  dimension  of  the  three-axis  systems 
engineering  morphology  described  by  Hall  [25]. 

•  Systems  engineering. 

•  Space  operations. 

•  Orbital  mechanics/satellite  dynamics. 

•  Astronautical  engineering. 

•  Mechanical  engineering. 

•  Electrical  engineering. 

•  Program  management. 

•  Simulation/control  theory. 

•  Software  design  and  integration. 

•  Telemetry  and  data  acquisition  system  design. 

•  Computer  architecture  design. 

2.2.4  Identification  of  Actors.  The  major  players  in  the  design  process 
and  their  contributing  roles  were  identified  to  ensure  success  in  the  design  effort  through 
recognition  of  their  concerns,  needs,  and  limitations. 

Lt  Col  Stuart  Kramer  and  Capt  Greg  Agnes,  USAF.  These  AFIT  instructors  were 
the  direct  customers  of  the  SIMS  AT  design,  thus  their  identified  needs  provided  the 


2-3 


primary  design  drivers.  As  sponsors  of  the  project,  they  also  served  as  the  chief 
decision  making  authority.1 

Systems  Design  Team.  The  team,  comprised  of  AFIT  Master’s  degree  candidates  in 
Space  Operations  and  Systems  Engineering,  was  responsible  for  the  design  and  inte¬ 
gration  of  the  system,  as  well  as  final  documentation  and  proposal. 

Mr.  Mike  Hanke.  A  fellow  AFIT  Master’s  candidate  in  Systems  Engineering,  Mr.  Hanke 
was  responsible  for  the  initial  selection  and  integration  of  a  computer-based  archi¬ 
tecture  for  the  system.  His  thesis,  “Design  of  the  Computer  Subsystem  for  the  AFIT 
Simulation  Satellite  ( SIMSAT )”  [26],  provides  the  principal  documentation  of  the 
computer-based  architecture  decisions.  His  work  was  concurrent  with  the  design 
team’s  work,  and  is  considered  a  companion  effort  to  the  design.2 

Mr.  Jay  Anderson.  An  AFIT  civilian  responsible  for  resource  acquisition  and  labora¬ 
tory  support,  Mr.  Anderson  was  the  focal  point  for  facilities  management,  experi¬ 
mental  support,  logistics  issues,  hardware  procurement,  and  safety-related  issues. 

Suppliers/Vendors.  Commercial  suppliers  were  the  primary  source  for  hardware  and 
software  used  in  the  system  design.  An  understanding  of  product  availability,  tech¬ 
nological  innovations,  and  customer  support  of  these  suppliers  was  critical  to  the 
design  effort. 

Indirect  Customers.  Some  of  the  additional  customers  considered  include  other  AFIT 
departments,  other  Air  Force  agencies,  and  joint  Department  of  Defense  agencies. 
These  indirect  considerations  play  a  significant  role  in  the  need  for  a  robust  and 
timely  design. 

2.2.5  Initial  Needs.  At  this  stage  of  the  design,  needs  were  identified 
in  general  terms  such  that  potential  solution  designs  could  be  conceived  and  explored. 

1  In  addition  to  serving  as  both  customers  and  chief  decision  makers,  Lt  Col  Kramer  and  Capt  Agnes 
were  instrumental  in  providing  direction  to  the  design  team.  Their  assistance  in  resolving  technical  issues 
and  design  trade-offs  made  this  effort  possible. 

2  Mr.  Hanke  was  a  member  of  the  systems  design  team  for  much  of  the  design  process.  His  work 
was  integral  to  the  overall  design,  and  does  not  represent  a  stand-alone  effort.  Many  of  the  computer 
architecture  decisions  (specifically,  the  command  and  data  handling  issues)  described  in  this  document  are 
a  result  of  Mr.  Hanke’s  work. 
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Actual  subsystem  requirements  and  quantitative  system  specifications  were  not  considered 
this  early  in  the  design  process.  The  following  list  summarizes  the  primary  needs  developed 
for  SIMS  AT  at  this  level  of  detail: 

•  Support  three-axis  control  for  detailed  experimentation.  Three-axis  stabilization  is 
required  for  the  primary  experimental  configuration. 

•  Support  dual-spin  demonstration  experiments,  which  involve  two  sections  of  the  satel¬ 
lite  model  to  simultaneously  rotate  relative  to  one  another. 

•  Support  pure  spinner  demonstration  experiments. 

•  System  should  be  robust  enough  to  support  a  multitude  of  experiments  requiring 
different  test  bed  configurations. 

•  Incorporate  the  air-bearing  assembly  (a  piece  of  test  equipment  that  allows  the  satel¬ 
lite  to  have  full  rotation  in  two  axes  and  partial  rotation  on  the  third  axis).  This 
air-bearing  mechanism  was  previously  purchased  expressly  for  this  project. 

•  Provide  unobstructed  satellite  model  maneuvering;  physical  connections  to  the  satel¬ 
lite  should  be  minimized  or  eliminated. 

•  Develop  a  ground  station  to  control  and  monitor  the  satellite  and  experimental  hard¬ 
ware. 

•  Provide  real-time  data  acquisition  and  command  capability  as  necessary. 

•  Provide  detailed  data  acquisition  for  post-test  analysis,  for  both  the  satellite  model 
and  experimentation  telemetry. 

•  Provide  pre-test  model  simulation  capability. 

•  Provide  for  real-time  and  post-test  graphical  representation  of  satellite  motion.  This 
need  is  highly  desired,  but  not  necessarily  required. 

•  Allow  emergency  shutdown  capability  for  the  system. 

2.2.6  Problem  Elements.  Once  the  needs  were  defined,  the  next  step  in 
the  design  process  was  to  identify  specific  elements  of  the  overall  problem  which  must  be 
addressed  by  the  system  architecture.  These  problem  elements  are  summarized  as  follows: 
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•  Rotating  the  satellite. 

•  Powering  the  satellite. 

•  Communicating  with  the  satellite. 

•  Predicting  satellite  behavior. 

•  Commanding  the  satellite. 

•  Collecting  and  analyzing  satellite  telemetry  and  experimental  data. 

•  Accommodating  a  variety  of  experiments. 

•  Providing  emergency  shutdown  of  the  satellite. 

•  Representing  the  behavior  of  the  satellite. 

2.2.7  Constraints  and  Alterables.  The  only  element  of  the  design 
which  is  considered  completely  unalterable  is  the  air-bearing  model  assembly.  Within 
budget  constraints  and  acceptability  criteria,  all  other  subsystems  and  components  of  the 
overall  system  are  considered  alterable,  and  the  overall  system  architecture  was  left  to  the 
discretion  of  the  design  team.  The  physical  location  of  the  SIMSAT  design  is  confined  to 
the  northwest  corner  of  Room  146,  Building  640,  of  the  AFIT  laboratories.  This  area  is 
approximately  240  square  feet.  Laboratory  lighting  limits  vertical  height  of  any  assembly 
to  approximately  15  feet.  The  computer-based  ground  station  should  incorporate  PC 
workstations,  which  can  be  networked  to  the  AFIT  system,  allowing  file  transfer  and 
use  of  AFIT  software,  such  as  Matlab  and  Simulink.  Compliance  with  AFIT,  Wright- 
Patterson  AFB,  Air  Force,  and  all  other  relevant  agency  policies  is  required.  These  policies 
pertain  to  safety,  power,  noise,  pollution,  radio  frequency,  and  hazardous  materials  issues. 

2.2.8  Cost  and  Schedule  Summary.  At  this  point  in  the  design,  specific 
cost  allocations  were  not  available,  but  a  budget  of  approximately  $100,000  was  considered 
an  upper  limit  (although  less  expensive  was  preferred).  A  design  timeline  was  formulated 
to  provide  a  schedule  at  this  stage.  The  significant  events  in  the  overall  SIMSAT  design 
timeline  are  summarized  below.  3 

3Note  that  this  schedule  was  constructed  during  the  Concept  Exploration  and  Definition  stage,  and  was 
subject  to  subsequent  change  as  later  design  issues  may  have  dictated. 
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Apr  98. 
Apr  98. 
May  98. 
Jun  98. 
Jun  98. 
Sep  98. 
Sep  98. 
Dec  98. 
Feb  99. 
Mar  99. 


Refine  problem  definition  and  attain  initial  needs  and  constraints. 
Begin  value  system  design  and  begin  system  synthesis. 

Refine  value  system  and  further  research. 

Perform  overall  system  evaluations. 

Complete  Concept  Exploration  and  Definition  phase. 

Complete  the  Preliminary  Design  phase. 

Order  subsystem  components  which  require  long  lead  times. 
Complete  Detailed  Design  phase.  Order  remaining  components. 
Complete  system  integration;  perform  system  test  and  evaluation. 
Present  final  system  design  and  associated  documentation. 


2.2.9  Value  System  Design.  At  this  stage  of  the  design  lifecycle,  it 
was  not  considered  productive  to  identify  specific  measurables  within  the  value  system 
to  compare  alternative  solutions  against.  Because  the  classes  of  solutions  may  be  very 
different,  the  solutions  might  not  compare  directly  using  detailed  objective  measurables. 
In  addition,  the  top-level  nature  of  solutions  at  this  stage  makes  direct  estimation  of 
quantitative  measurables  difficult,  if  not  impossible.  Instead,  the  value  system  at  this  stage 
should  provide  a  framework  wherein  each  broad  solution  can  be  considered.  If  the  value 
system  without  specific  measurables  allows  differentiation  of  these  solutions,  then  it  serves 
the  purpose  of  identifying  the  most  promising  class  or  classes  of  solutions  at  this  stage.  If 
no  significant  differentiation  can  be  made  between  solution  classes,  further  refinement  of 
the  value  system  design  may  be  required,  to  include  more  specific  measurables. 

The  primary  system  objectives  were  identified  as  cost  minimization,  performance 
maximization,  and  safety  maximization.  The  top-level  objective  hierarchy  is  illustrated  in 
Figure  2.2.  Each  objective  is  defined  to  allow  a  consistent  and  informative  application  of 
the  value  system  against  all  potential  solutions.  The  definitions  which  follow  explain  the 
intent  of  each  objective  within  the  value  system  at  this  level. 

•  Total  Cost.  System  cost  to  bring  the  system  on-line;  consider  the  purchase  and 
integration  costs. 
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Figure  2.2  Initial  Value  System  Design  (VSD) 

•  Total  Time.  Total  timeframe  to  bring  the  system  on-line;  consider  the  purchase  and 
integration  time  requirements. 

•  Data  Capability.  Consider  both  data  which  can  be  displayed  real-time,  as  well  as  the 
post-experiment  data  analysis  capability. 

•  Ease  of  Use.  Consider  the  user  interface  and  how  easy  it  is  to  switch  compo¬ 
nents/experiments  on  the  model. 

•  Simulation  Fidelity.  Consider  how  well  a  computer  simulation  model  could  represent 
the  physical  model’s  behavior,  and  consider  how  easy  it  is  to  develop  the  simulation 
model. 

•  Command  and  Control.  Consider  how  well  the  system  does  what  is  desired,  how 
responsive  it  is,  and  how  autonomous  it  is. 

•  Robustness.  Consider  the  range  of  experiments  the  system  can  support. 
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•  Angular  Capability.  Consider  the  system’s  ability  to  move  rapidly  (high  slew  rate) 
to  the  desired  position  (high  sensing  accuracy)  and  stabilize. 

•  Hazard  Severity.  Estimate  the  system  hazard  severity  in  terms  of  potential  damage 
to  equipment  or  injury  to  personnel. 

•  Number  of  Hazards.  Estimate  the  total  number  of  significant  hazards  inherent  to  the 
system. 

2.2.10  System  Architecture  Development.  Using  the  problem  ele¬ 
ments  discussed  in  Section  2.2.6,  an  initial  system  architecture  was  developed  to  meet  the 
needs  of  the  system  and  provide  a  basis  for  system  synthesis  (generation  of  alternatives). 
The  initial  system  architecture  also  allowed  identification  of  the  system  boundary  and 
environment,  and  resulted  in  the  system  context  diagram  shown  in  Figure  2.3. 
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2.2.11  System  Decomposition.  The  subsystems  identified  in  Figure  2.3 
resulted  from  analysis  of  the  problem  elements,  and  a  functional  approach  to  addressing 
these  elements.  Initial  system  decomposition  into  subsystems  took  several  forms,  with  the 
subsystems  shown  in  Figure  2.3  finally  chosen  as  the  preferred  system  decomposition. 

A  software/hardware  breakdown  was  rejected  due  to  the  strong  interdependencies  of 
computer  software  and  hardware  solutions.  Furthermore,  this  breakdown  did  not  aid  in 
development  of  solution  alternatives  since  the  specific  problem  elements  are  not  addressed 
using  this  format.  Similarly,  a  ground  station/satellite  breakdown  was  also  rejected  since 
functional  divisions  were  overridden  by  physical  divisions  in  this  decomposition. 

As  stated  above,  the  system  decomposition  of  Figure  '2.3  is  based  on  functional 
breakdown,  and  was  modeled  after  the  spacecraft  subsystem  breakdown  used  in  the  Space 
Mission  Analysis  and  Design  (SMAD)  textbook  by  Larsen  and  Wertz  [33:287].  The  “Guid¬ 
ance,  Navigation,  and  Control”  function  identified  in  the  SMAD  text  was  ignored  since 
the  simulator  model  is  fixed  in  the  laboratory.  Thus,  guidance  and  navigation  represent 
attitude  positioning  only,  which  is  handled  by  the  “Attitude  Determination  and  Control 
System”  (ADACS).  The  thermal  subsystem  identified  by  SMAD  was  eliminated  from  ini¬ 
tial  consideration  as  a  separate  subsystem  because  operating  conditions  were  not  expected 
to  require  dedicated  thermal  elements.  If  system  operation  required  cooling  of  compo¬ 
nents,  later  stages  of  development  could  address  environmental  control  mechanisms.  The 
other  subsystem  divisions  are  very  similar  to  the  SMAD  text  definitions.  The  following 
list  defines  the  system  decomposition  used  in  the  SIMS  AT  design: 

ADACS.  The  ADACS  consists  of  three  components:  attitude  deter¬ 
mination  equipment,  attitude  control  equipment,  and  control  software.  The  attitude  de¬ 
termination  equipment  determines  the  system’s  actual  position/orientation  and  provides 
information  used  to  develop  inputs  for  the  attitude  control  mechanisms.  The  attitude 
control  equipment  provides  the  necessary  forces  and  torques  on  the  system  based  on  infor¬ 
mation  from  the  user  or  attitude  determination  and  control  software  inputs.  The  control 
software  element  consists  of  software  code  incorporating  control  laws  which  provide  the 
logic  used  to  provide  the  proper  inputs  to  the  attitude  control  equipment.  The  ADACS 
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subsystem  addresses  the  following  problem  elements  identified  in  Section  2.2.6:  “moving 
the  satellite”,  “predicting  satellite  behavior”,  “and  representing  the  behavior  of  the  satel¬ 
lite”. 


Power  System .  The  power  subsystem  includes  elements  associated 

with  the  supply,  regulation,  and  distribution  of  necessary  voltages  and  currents  to  operate 
all  the  onboard  subsystems.  This  subsystem  addresses  the  problem  element  “powering  the 
satellite” . 


Command  and  Data  Handling  System .  The  C&DH  subsystem 

receives,  decodes,  processes,  and  distributes  all  satellite  commands.  Moreover,  it  gathers, 
formats,  stores,  and  transmits  telemetry  data  from  the  onboard  systems  and  experiments, 
as  well  as  the  ground  station.  This  definition  of  the  C&DH  system  is  taken  from  the  SMAD 
text  [33:288].  Within  the  C&DH  is  the  inherent  computer  architecture  to  perform  these 
tasks,  addressing  the  problem  elements  “commanding  the  satellite”  and  “collecting  and 
analyzing  satellite  telemetry  and  experimental  data” . 

Communications .  The  communications  subsystem  represents  the 
interface  between  the  satellite  model  and  the  ground  station.  The  communications  system 
is,  in  effect,  an  extension  of  the  C&DH  subsystem,  linking  the  simulator  C&DH  elements 
with  the  ground  station  C&DH  elements  and  thus  performing  the  “communicating  with  the 
satellite”  function  listed  in  the  problem  elements.  Thus,  the  communications  and  C&DH 
subsystems  are  shown  in  Figure  2.3  as  slightly  overlapped. 

Structures  and  Interfaces .  This  subsystem  represents  the  physical 
satellite  model  assembly,  to  include  subsystem  housing,  structural  supports,  fasteners, 
and  physical  interfaces  between  the  base  model  and  experimental  hardware.  Although 
each  subsystem  must  consider  the  following  problem  element,  this  subsystem  addresses 
“accomodating  a  variety  of  experiments”  most  directly. 

2.2.12  System  Synthesis.  Once  a  broad  system  architecture  was  con¬ 
ceived,  the  next  task  was  the  identification  of  feasible  solutions  through  the  development 
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of  a  list  of  potential  subsystem  alternatives,  which  can  be  integrated  to  create  feasible  sys¬ 
tem  alternatives.  These  subsystem  alternatives  were  the  result  of  creative  brainstorming 
and  research  into  actual  satellite  systems,  laboratory-based  systems,  flight  test  systems, 
and  emerging  technologies.  Thus,  a  certain  amount  of  knowledge  must  be  first  developed 
in  order  to  generate  solutions.  Subsystem  alternatives  are  described  in  the  sections  that 
follow. 

2.2.12.1  ADACS  Background.  As  a  first  step  in  the  synthesis  of 
ADACS  alternatives,  further  investigation  into  the  methods  of  satellite  stabilization  was 
undertaken.  From  this  point,  alternatives  can  be  conceived  to  apply  the  necessary  sta¬ 
bilization  techniques  such  that  the  needs  of  the  user  are  satisfied.  This  section  provides 
background  on  the  methods  of  satellite  stabilization  requested  by  the  user,  which  precedes 
the  discussion  of  the  various  subsystem  alternatives  considered  in  this  phase. 

Spin  stabilization  generally  involves  a  torque-free,  axisymmetric  body  whose  spinning 
motion  about  a  given  principal  axis  prevents  small,  external  torques  from  perturbing  the 
satellite’s  motion.  “Axisymmetric”  is  defined  as  having  two  principal  moments  of  inertia 
being  equal.  A  general  rigid  body  has  three  principle  moments  of  inertia  which  are  oriented 
about  the  body’s  principal  axes.  In  Figure  2.4(a),  the  first  moment  of  inertia,  A,  is  oriented 
along  the  bl  axis.  The  second  moment  of  inertia,  B,  rests  along  the  b2  axis,  and  C  rests 
along  the  b3  axis.  In  this  case,  A  is  the  “major  axis”  of  inertia  (greatest  moment  of  inertia). 

As  requested  by  the  customer,  SIMS  AT  should  provide  examples  of  both  prolate  and 
oblate  spinners.  Prolate  bodies,  best  described  as  cigar-shaped  objects,  have  two  identical 
moments  of  inertia  with  a  third,  smaller  moment  of  inertia,  as  shown  in  Figure  2.4(b). 
With  a  prolate  spinner,  the  satellite  rotates  about  the  b3  axis.  Since  this  axis  has  the 
smallest  moment  of  inertia,  the  body  is  said  to  spin  about  its  minor  axis.  However,  a  body 
spinning  about  its  minor  inertia  axis  is  naturally  stable  only  in  the  case  of  a  completely 
rigid  body,  which  is  not  generally  achievable  in  practice.  Therefore,  remaining  stable  with  a 
prolate  configuration  requires  the  use  of  aggressive  attitude  control  to  maintain  a  constant 
angular  velocity. 
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(a)  Moments  of  Inertia 


(b)  A  Prolate  Body 


(c)  An  Oblate  Body 


Figure  2.4  Satellite  Inertia  and  Stabilization  Concepts 


An  oblate  body,  the  proverbial  “tuna  can”  geometry,  has  a  third  moment  of  inertia 
which  is  larger  than  the  other  two  moments  of  inertia.  From  Figure  2.4(c),  the  b3  axis  is 
the  major  inertia  axis.  Therefore,  an  oblate  body  spinning  about  the  b3  axis  in  a  stable 
mode  requires  fewer,  if  any,  attitude  control  inputs  to  maintain  stability. 

Dual  spin  stability  involves  two  sections  of  a  satellite  which  rotate  relative  to  one 
another.  The  first  (usually  larger)  section,  the  rotor,  rotates  at  an  angular  velocity  ur  to 
maintain  stability  for  the  satellite.  The  second  portion,  the  platform,  rotates  at  a  different 
rate  up.  In  this  way,  the  platform  section  can  be  maintained  at  a  constant  orientation 
relative  to  the  ground  to  maintain  a  constant  pointing  attitude  for  the  payload4.  Figure  2.5 
illustrates  the  dual  spin  configuration. 


Figure  2.5  Dual  Spin  Configuration 

Three  axis  stabilization  is  the  most  widely  used  method  on  modern  day  satellites. 
This  stabilization  technique  requires  the  capability  to  produce  torques  in  each  axis  using 
active  control.  Usually,  an  inertial  platform  is  maintained  onboard  using  a  combination  of 
software  logic  and  hardware  actuation  systems.  Compared  to  the  previous  two  stabilization 

4For  example,  this  technique  can  be  used  to  accommodate  a  communications  link  with  degraded  omni¬ 
directional  performance. 
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methods,  three  axis  stabilization  requires  a  greater  combination  of  components.  This 
method  often  utilizes  determination  and  control  hardware  redundancy  to  ensure  pointing 
accuracy. 

2.2.12.2  ADACS  -  Attitude  Determination.  Having  discussed  the 
three  types  of  stability  which  are  necessary  for  the  SIMSAT  system,  the  next  endeavor 
involved  brainstorming  ideas  for  attitude  determination  and  attitude  control  components. 
For  the  attitude  determination  alternatives,  there  are  two  major  classes  of  systems  available 
for  SIMSAT-  passive  and  active.  Passive  systems  are  divided  into  inertial  measurement 
units  and  IR/optical  sensors.  They  are  considered  passive  mechanisms  since  they  detect 
changes  through  observation.  Alternatively,  active  mechanisms  emit  energy  to  measure 
differences  in  position.  Active  systems  include  radio  interferometers  and  laser  grids.  The 
following  list  summarizes  the  attitude  determination  alternatives  conceived  in  this  phase 
and  identifies  some  of  the  feasibility  considerations  associated  with  their  use: 

Inertial  Measurement  Units.  Inertial  measurement  units  (IMUs) 
measure  rotational  motion  through  the  use  of  gyroscopes  (mechanically  gimbaled  systems) 
or  high  resolution  software  (strap  down  units).  The  IMU  is  first  set  to  a  zero  point. 
Afterwards,  whenever  the  satellite’s  orientation  changes,  the  IMU  measures  its  deflection 
from  the  initial  point  to  determine  by  how  much  the  orientation  has  changed.  The  main 
concern  with  IMUs  is  determining  the  drift  rate  of  the  sensors.  For  extended  experiments, 
the  drift  rate  could  cause  readings  to  be  inaccurate.  Typical  drift  rates  are  0.005° /hr  and 
3°/hr  [33:360]. 


Sun  Sensor.  Sun  sensors  are  visible  light  detectors  which  are  used 
to  measure  the  relative  angles  between  its  mounting  plate  and  incident  sunlight.  For  the 
system  design,  this  option  involves  mounting  an  external  light  source  within  the  laboratory 
which  acts  as  an  artificial  sun.  The  typical  pointing  accuracy  for  this  option  is  between 
0.005°  and  3°  [33:360]. 

Star  Sensor.  Star  sensors  use  a  variety  of  methods  to  determine 
vehicle  attitude  using  the  relative  positions  of  stars.  Based  on  fixid  pointing  accuracy, 
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the  best  candidate  for  the  system  design  involves  using  a  star  tracker  which  “uses  a  wide 
field  of  view,  scanning  electronically  until  it  locates  and  tracks  a  star  of  predetermined 
brightness.”  [33:361].  Following  successful  acquisition  and  tracking,  any  change  in  the 
apparent  position  of  the  star  within  the  field  of  view  corresponds  to  a  change  in  vehicle 
orientation.  Similar  to  the  tracker,  the  star  mapper  uses  several  stars  in  its  field  of  view. 
The  typical  attitude  accuracy  for  this  option  is  between  0.0003°  and  0.01°  [33:360].  An 
artificial  “star”  constellation  within  the  laboratory  would  be  required. 

Horizon  Sensor.  Horizon  sensors  are  infrared  devices  used  by 
satellites  which  detect  the  “hot”  surface  of  the  earth  compared  to  the  “cold”  vacuum  of 
space.  The  system  uses  clear  fields  of  view  with  various  scan  widths  to  determine  its 
position  relative  to  the  body  being  scanned.  For  this  design,  a  heated  body  in  a  fixed 
location  within  the  design  room  would  act  as  the  Earth’s  surface.  Typical  accuracy  for 
this  alternative  is  between  0.1°  and  1°  [33:360]. 

Magnetometers.  Magnetometers  are  used  to  measure  the  direction 
and  size  of  the  earth’s  magnetic  field  to  determine  satellite  attitude  and  position.  Attitude 
accuracy  is  between  0.5°  and  3°.  For  SIMS  AT,  a  contained,  variable  magnetic  field  would 
be  needed  for  the  magnetometers  to  monitor. 

Radio  Interferometers.  Radio  interferometers  are  used  for  dis¬ 
tance  determinations  of  celestial  bodies  in  astronomical  applications.  Two  parabolic  dishes 
are  set  a  fixed  distance  apart;  returning  radio  waves  are  recorded  with  an  amount  of  in¬ 
terference  between  them.  The  interference  pattern  is  analyzed  by  software  and  determines 
the  distance  between  the  dish  array  and  the  emitting  body. 

Laser  Grid.  Use  of  an  external  laser,  in  conjunction  with  a  finely 
etched  grid  upon  the  satellite  assembly,  could  potentially  allow  position  information  to  be 
calculated  based  on  the  number  of  grid  lines  which  pass  through  the  laser  focus.  This  idea, 
borrowed  from  laser  Doppler  velocimetry  techniques,  was  innovative  but  unproven. 
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2.2.12.3  ADACS  -  Attitude  Control.  For  the  attitude  control  com¬ 
ponents  of  ADACS,  there  are  three  major  solution  classes  -  momentum  exchange  systems, 
mass  expulsion  systems,  and  other  external  systems.  These  classes  are  discussed  below: 

Momentum  Exchange  Methods.  Reaction  wheels  are  essentially 
“high  torque  motors  with  high-inertia  rotors.”  [33:352].  In  cases  where  the  satellite  is 
disturbed  by  external  forces,  the  reaction  wheels  spin  in  either  direction  to  absorb  the 
momentum  imparted  on  the  system.  Eventually,  the  reaction  wheels  must  perform  mo¬ 
mentum  dumps  to  avoid  saturation.  It  is  necessary  to  have  at  least  three  reaction  wheels 
for  three-axis  control.  Momentum  wheels  differ  from  reaction  wheels  in  that  they  have  a 
nominal  spin  rate  which  provides  a  constant  angular  momentum  to  the  system.  By  provid¬ 
ing  a  constant  angular  momentum,  this  method  provides  “gyroscopic  stiffness  in  two  axes, 
while  the  motor  torque  is  controlled  to  precisely  point  around  the  third  axis.”  [33:352].  As 
with  the  reaction  wheels,  excess  momentum  must  be  dumped  from  the  wheels  to  prevent 
saturation.  It  is  also  necessary  to  have  at  least  three  wheels  for  three-axis  control.  Control 
moment  gyros  are  single  or  double-gimbaled  wheels  which  spin  at  a  constant  speed.  High 
output  torques  about  the  three  body  axes  are  created  by  moving  about  the  gimbal  axes. 
Control  laws  for  this  system  are  more  complex  than  with  reaction/momentum  wheels. 

Mass  Expulsion  Methods.  Gas  jets  and/or  thrusters  are  bipropel¬ 
lant,  monopropellant,  or  cold  gas  systems  which  produce  torque  by  expelling  mass  through 
a  nozzle.  The  components  for  this  alternative  include  a  storage  tank,  feed  lines,  and  a  noz¬ 
zle  with  a  control  valve. 

External  Methods.  Magnetic  torquers  use  electromagnets  or  mag¬ 
netic  coils  to  generate  magnetic  dipole  moments  to  move  a  vehicle  through  an  external 
magnetic  field.  Satellite  applications  include  compensating  for  drift  associated  with  minor 
disturbance  torques,  compensating  for  the  vehicle’s  residual  magnetic  fields,  and  slowly 
desaturating  momentum  exchange  systems  [33:356].  As  another  option,  external'air  cur¬ 
rents  applied  by  the  SIMS  AT  operator  to  specific  locations  on  the  vehicle  could  be  used 
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for  initial  spin  stabilization.  At  this  point,  the  attitude  control  element  becomes  more  art 
than  science. 

2.2.12.4  ADACS  -  Control  Laws.  The  control  laws  and  logic  within 
the  software  controllers  are  used  to  translate  data  received  from  the  attitude  determina¬ 
tion  components  into  input  commands  supplied  to  the  applicable  actuation  mechanisms. 
At  this  point  in  the  concept  exploration  phase,  detailed  discussions  were  not  warranted. 
However,  there  are  three  alternatives  for  system  design.  First,  the  design  team  could  have 
developed  control  laws  using  already  existing  software  packages  such  as  Matlab/Simu- 
link  or  computer  code  (such  as  C-code).  Second,  due  to  the  fact  that  the  system  will  be 
used  for  a  variety  of  experiments,  the  control  laws  could  be  developed  by  the  user.  This 
option  would  require  the  system  to  be  compatible  with  a  multitude  of  software  packages 
with  proper  interfaces.  Finally,  the  control  laws  could  be  developed  by  a  contractor. 

2.2.12.5  Power.  A  primary  concern  for  system  operation  was  the  pro¬ 
vision  for  electrical  power  to  various  subsystems  located  onboard  the  satellite.  The  use  of 
momentum  exchange  devices  such  as  momentum  wheels  or  control  moment  gyros  requires 
substantial  amounts  of  power  for  motor  startup,  changing  torque  outputs,  and  inherent 
frictional  losses.  Additionally,  communication,  C&DH,  and  other  onboard  subsystems  re¬ 
quire  power  for  system  operation. 

During  this  phase  of  design,  several  methods  of  onboard  energy  production  and 
storage  were  considered.  A  wide  variety  of  potential  energy  sources  were  brainstormed, 
although  most  were  deemed  infeasible  upon  review.  Potential  energy  sources  included 
photovoltaic  cells,  fuel  cells,  thermal  batteries,  and  chemical  batteries.  Other  possible 
methods  of  energy  production,  such  as  directed  energy  transmission,  radio-isotopic  decay, 
or  internal  combustion,  were  immediately  deemed  unacceptable  due  to  cost,  weight,  or 
safety  considerations. 

2.2.12.6  C&DH  .  The  C&DH  subsystem  has  two  main  purposes:  in¬ 
terface  with  the  user  and,  as  required,  execute  the  actual  control  laws  determining  how 
the  effectors  (devices  that  cause  something  to  happen)  are  activated  to  respond  to  com- 
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mands.  Theoretically,  the  control  system  could  be  as  simple  as  a  direct  connection  between 
the  user  controls  and  the  effectors  (similar  to  the  mechanical  control  systems  of  early  air¬ 
craft).  Because  this  approach  creates  a  tremendous  workload  for  the  operator,  engineers 
have  tried  to  find  ways  to  improve  the  design  of  control  systems.  To  determine  the  best 
C&DH  design  concept,  some  point  solutions  in  the  spectrum  from  simple,  direct  control 
systems  to  sophisticated  computer  control  systems  were  considered.  All  these  alternatives 
assume  the  other  SIMS  AT  subsystems  (ADACS,  power,  communications,  and  structures) 
will  be  sufficiently  designed  to  allow  for  full  subsystem  capability.  The  C&DH  subsystem 
technology  alternatives  include  the  following  classes: 

Direct  Control.  The  direct,  unassisted  control  option  consisted  of 
a  user  interface  comprised  of  knobs,  levers,  switches,  dials,  display  panels,  and/ or  lights. 
The  commands  (from  the  knobs,  levers,  and/or  switches)  would  be  converted  to  a  format 
that  could  be  transmitted  to  the  satellite,  where  they  would  be  converted  back  to  a  format 
required  by  the  effectors.  The  results  of  those  commands  would  be  sensed,  converted  to 
the  transmission  format,  and  then  sent  to  the  ground  station  where  it  would  be  converted 
to  a  format  consistent  with  the  dials,  display  panels,  and/or  lights.  This  functionality 
would  require  substantial  research  to  locate  compatible  components,  integrate  them,  and 
troubleshoot  the  system  should  problems  arise. 

Analog  Control.  The  analog  computer-assisted  control  option  con¬ 
sisted  of  a  user  interface  very  similar  to  the  “direct”  system  above.  Control  law  imple¬ 
mentation/adaptation  would  be  handled  by  changing  individual  components.  Before  the 
recent  advancements  in  digital  computer  hardware  and  software,  analog  computers  were 
considered  the  preferred  solution  for  real-time  control  due  to  reduced  execution  delay. 
Analog  control  box  designs  provide  some  flexibility  by  allowing  “building  block”-type  im¬ 
plementations  (reducing  the  likelihood  of  component  incompatibilities),  reducing  research, 
implementation,  and  troubleshooting  time.  However,  analog  computer  technology  is  not 
as  well  understood  or  supportable  as  digital  technology. 
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Digital  Control  (Text).  The  digital  computer-assisted  control 
option  was  based  on  a  command-line  (or  “text”)  user  interface.  Control  law  implementation 
and  modification  would  be  handled  by  well-defined  software  packages  available  for  a  number 
of  different  hardware  platforms.  Integrated  subsystem  implementation  is  similar  to  the 
analog  computer  approach,  but  more  “building  block”  components  are  available.  Expertise 
in  these  systems  is  more  readily  available  as  well. 

Digital  Control  ( Graphical).  This  solution  class  consisted  of  a  dig¬ 
ital  computer- assisted  control  system,  with  a  visual/graphically-based  user  interface.  All 
the  design  advantages  of  the  above  classes  of  technologies  exist  with  the  added  intuitive¬ 
ness  of  the  graphical  development  environment.  Using  the  integrated  hard  ware /soft  ware 
solution  provided  by  dSPACE,  Inc.5,  reduces  the  testing  and  troubleshooting.  Substantial 
in-house  and  proximate  technical  support  exists  for  this  system. 

2.2.12.7  Communications.  As  stated  previously,  the  communications 
subsystem  provides  the  data  link  between  the  ground  station  and  the  satellite.  Alternatives 
were  generated  by  researching  the  data  transfer  systems  used  in  satellite  operations,  flight 
test  operations,  and  computer  networks.  These  applications  require  wireless  solutions, 
consistent  with  the  needs  of  the  SIMS  AT  design.  The  following  list  describes  the  classes 
of  communication  alternatives: 

Flight  Test  Telemetry  Systems.  Flight  test  telemetry  systems 
are  used  in  many  aircraft  and  missile  testing  applications.  A  typical  setup  includes  a  data 
bus  monitoring  unit  to  collect  vehicle  data,  a  multiplexer  to  format  data  for  transmission, 
a  transmitter  antenna  (typically  S-band),  a  receiver  unit  to  receive  commands,  and  a 
decoder  unit  to  interpret  commands  (sometimes  integrated  with  the  receivers).  This  type 
of  system  can  be  tailored  to  the  problem  at  hand,  but  is  mostly  designed  for  long-range  data 
transmission  in  open-air  environments  (unlike  a  laboratory).  Figure  2.6  shows  a  typical 
flight  test  telemetry  system  schematic. 

5 A  graphics-based  data  handling  system  developed  by  dSPACE,  Inc.,  of  Germany  was  already  purchased 
for  possible  use  in  this  project  prior  to  actual  system  design.  However,  implemention  of  the  dSPACE  system 
was  left  as  an  option  for  the  design  team  to  consider. 
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Figure  2.6  Flight  Test  Telemetry  System  Schematic 

Satellite  Relays .  Also  used  in  flight  test  applications,  as  well  as 
many  wireless  telecommunication  systems,  satellite  relay  systems  use  existing  satellites  to 
link  one  user  to  another,  such  as  a  ground  station  to  a  test  vehicle.  These  commercially- 
available  solutions  are  impractical  for  a  laboratory  environment  in  which  data  transmission 
lengths  are  only  several  feet.  Thus,  this  solution  class  was  determined  to  be  unrealistic 
prior  to  more  formal  analysis  and  modeling. 

Wireless  Modems.  Wireless  modem  systems  have  been  used  in 
industrial  applications  for  some  time  now.  They  are  used  in  many  radio  control  applica¬ 
tions,  ranging  from  remote  sensing  and  control  to  telemetry  data  collection.  The  primary 
drawback  of  a  wireless  modem  solution  is  the  low  data  rates  achievable  using  current 
technology. 


2-21 


Wireless  Local  Area  Network  (LAN).  Wireless  LANs  are  increas¬ 
ing  in  popularity  and  application.  A  wireless  LAN  system  allows  computers  to  network 
to  each  other  via  wireless  technologies  (typically  IR/RF  transmitters/receivers).  Inher¬ 
ent  in  the  wireless  LAN  concept  is  the  need  for  a  ground  station  computer  as  well  as  a 
sophisticated  computer  architecture  onboard  the  satellite. 

2.2.12.8  Structures.  At  this  stage  in  the  design,  the  structural  configu¬ 
ration  of  the  satellite  was  not  well  developed.  Thus,  the  generation  of  different  structured 
solutions  was  not  practical  at  this  point.  For  the  most  part,  the  structure  of  the  satel¬ 
lite  was  driven  by  the  choice  of  subsystems,  the  expertise  of  the  fabrication  shop,  and 
stability/slewing  requirements. 

2.2.12.9  Subsystem  Alternatives.  The  list  of  SIMSAT  subsystem 
alternatives  is  summarized  in  Table  2.1.  These  subsystems  represented  the  system  synthesis 
step  in  the  Concept  Exploration  and  Definition  phase. 

2.3  Analysis 

2.3.1  Analysis  Methodology.  A  primary  task  of  the  Concept  Exploration 
and  Definition  phase  was  to  eliminate  those  subsystem  alternatives  which  were  determined 
to  be  infeasible,  impractical,  or  relatively  inferior  to  other  alternatives.  “Mental  modeling” 
was  the  primary  method  for  analyzing  subsystem  alternatives  during  this  phase.  Mental 
modeling  relies  on  expert  opinion,  personal  experience,  research,  and  common  sense  rather 
than  on  sophisticated  models  or  rigorous  mathematical  analysis.  Mental  modeling  was  an 
efficient  tool  for  making  a  top  level  “first  cut”  between  feasible  and  infeasible  alternatives. 
In  order  to  augment  this  mental  modeling,  the  SMAD  text  was  often  used  as  a  source 
for  expert  opinion  or  rudimentary  math  calculations.  The  following  paragraphs  document 
the  mental  modeling  used  to  select  a  set  of  feasible  solution  classes  through  elimination  of 
impractical  alternatives. 

2.3.2  Attitude  Determination  and  Control.  The  main  requirements 
for  the  system  which  pertain  to  ADACS  were  pointing  accuracy,  highest  achievable  slew 
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Table  2.1  Concept  Exploration  and  Definition  Subsystem  Alternatives 


Subsystem 

Alternatives 

Attitude  Determination 

IMUs 

Sun/Star/Horizon  Sensors 
Magnetometers 

Radio  Interferometers 

Laser  Grid 

Attitude  Control 

Momentum  Exchange 

Mass  Expulsion 

External  Forces 

Power  Generation  & 
Distribution 

Photovoltaic  Cells 

Fuel  Cells 

Thermal  Batteries 
Chemical  Batteries 

Command  & 

Data  Handling 

Direct  Control 

Analog  Computer 

Digital  Computer  (Text) 
Digital  Computer  (Graphical) 

Communications 

Flight  Test  Telemetry 
Wireless  Modem 

Wireless  LAN 

Structures 

As  Required 

rate,  and  the  capability  to  perform  pure  spin,  dual  spin,  and  three  axis  stabilization. 
During  follow-on  interviews  with  the  customer,  a  pointing  accuracy  of  0.005°  and  slew  rate 
minimum  of  10° /sec  were  identified  as  system  requirements.  Quantitative  requirements  at 
this  stage  were  necessary  in  order  to  differentiate  between  solution  classes,  exemplifying 
the  iterative  nature  of  the  systems  engineering  process. 

Passive  attitude  determination  methods  via  sun  sensors,  star  sensors,  horizon  sensors, 
and  magnetometers  were  eliminated  from  further  consideration,  as  they  did  not  meet 
these  specifications  in  practical  application.  The  sun  and  star  sensors,  although  capable 
of  meeting  the  pointing  accuracy  requirement,  necessitated  the  design  of  an  artificial  star 
field  or  point  light  source  within  the  laboratory,  and  would  be  of  limited  use  for  high 
slew  maneuvers.  Horizon  sensors  and  magnetometers  did  not  meet  pointing  and  accuracy 
requirements,  and  would  also  be  less  precise  during  high  slew  maneuvers. 
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Instead  of  developing  an  in-house  sun/star  sensor  system,  the  choice  of  IMUs  for 
attitude  determination  allowed  use  of  commercial  off-the-shelf  hardware.  Since  the  use 
of  IMUs  is  fairly  standard  for  attitude  determination  systems,  their  choice  allowed  for 
confidence  in  achieving  the  pointing  and  attitude  accuracy  requirements. 

Active  attitude  determination  methods  via  radio  interferometers/Doppler  shift  mea¬ 
surement  or  laser  grid  tracking  were  determined  to  be  impractical.  Again,  these  methods 
did  not  meet  the  pointing  accuracy  requirement  and/or  they  required  extensive  manipu¬ 
lation  of  the  environment.  The  use  of  the  laser  grid  system  also  required  expensive  laser 
components  and  undesirable  machining  of  the  air  bearing  assembly. 

For  attitude  control,  the  use  of  magnetic  torquers  or  external  air  currents  required 
extreme  sophistication  to  meet  the  pointing  accuracy  requirement  or  the  10° /sec  slew  rate 
requirement,  and  thus  they  were  judged  to  be  impractical.  The  use  of  momentum  exchange 
methods,  such  as  control-moment  gyros  (CMGs)  or  momentum  wheels,  appeared  to  meet 
the  ADACS  requirements.  Mass  expulsion  methods,  such  as  gas  jets,  were  deemed  to 
be  impractical  for  fine  attitude  control  due  to  the  pointing  accuracy  required.  However, 
this  option  had  practical  value  as  a  secondary  means  to  achieve  higher  slew  rates  or  to 
dump  momentum.  Depending  on  the  capacity /capability  of  a  momentum  exchange  system, 
thrusters  were  considered  to  be  of  future  value. 

In  summary,  the  general  ADACS  solution  classes  under  consideration  following  Con¬ 
cept  Exploration  and  Definition  were  IMUs  for  attitude  determination  and  momentum 
exchange  (with  mass  expulsion  as  necessary)  for  attitude  control.  Specific  decisions  on  the 
software  control  laws  were  not  made  at  this  level. 

2.3.3  Power.  Microwave  transmission  and  radio-isotopic  power  sources  were 
eliminated  because  of  safety  risks.  Fuel  cells  were  also  eliminated  because  of  safety  concerns 
related  to  their  use  of  flammable  and  explosive  materials.  The  use  of  a  momentum  wheel’s 
kinetic  energy  as  a  power  source  was  considered  dining  analysis.  This  alternative  could 
perhaps  be  explored  as  a  future  experiment  to  be  tested  on  SIMS  AT,  but  the  idea  was 
deemed  too  revolutionary  to  be  used  as  a  primary  power  source. 
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A  photovoltaic  power  source  (solar  cell  system)  was  also  determined  infeasible  for 
SIMS  AT.  In  order  to  analyze  the  solar  cell  alternative,  a  gross  estimate  of  the  final  SIMS  AT 
design  was  presumed  and  basic  calculations  were  made.  General  characteristics  for  solar 
cell  systems  were  extracted  from  SMAD  [33:317].  For  a  SIMSAT  device  requiring  250 
Watts  of  power  (constant  load),  at  least  10  kg  of  system  mass  would  be  required  for  a 
photovoltaic  array.  More  importantly,  the  total  surface  area  required  to  produce  250  Watts 
is  between  2.5  and  10  square  meters  depending  upon  assumptions  regarding  the  ambient 
lighting  present  in  the  experimental  setup  area.  This  large  area  requirement  exceeds  the 
reasonable  bounds  for  SIMSAT  overall  size. 

Although  solar  power  is  the  preferred  option  in  many  space  applications  due  to 
mission  lifetime  and  relatively  low  power  requirements,  the  need  for  SIMSAT  to  operate  at 
high  power  levels  for  short  experiment  times  suggests  the  use  of  chemical  energy  storage. 
In  comparison  to  solar  cells,  a  power  system  capable  of  providing  250  watts  (constant 
load)  for  thirty  minutes  using  nickel-cadmium  batteries  would  require  between  2.5  to  5.5 
kg  of  system  mass  with  significantly  less  volume.  Based  upon  this  top-level  analysis, 
chemical  batteries  appeared  to  be  a  reasonable  and  effective  power  source,  and  they  do 
not  require  extensive  external  lighting.  The  use  of  thermal  batteries  was  less  attractive 
than  chemical  batteries  for  two  primary  reasons:  they  generate  intense  heat,  and  they  are 
non-rechargeable. 

2.3.4  Command  and  Data  Handling.  ADACS,  power,  and  commu¬ 
nications  subsystems  were  all  dependent  on  the  choice  of  C&DH  architecture.  Thus,  an 
early  choice  for  the  C&DH  architecture  was  critical  to  the  overall  system  architecture.  The 
VSD  in  Figure  2.2  represents  the  first  step  in  conceptualizing  what  values  were  a  part  of 
the  overall  attempt  to  satisfy  the  customer.  At  this  level  of  design  abstraction,  there  was 
no  point  in  determining  the  quantitative  characteristics  of  each  C&DH  alternative  —  they 
have  not  been  fully  defined  at  this  stage,  making  it  impossible  to  establish  actual  measures 
of  merit. 

The  qualitative  assessment  of  the  ability  of  each  class  of  C&DH  solutions  to  satisfy 
the  objectives  is  discussed  at  length  in  the  AFIT  Master’s  thesis  of  Mr.  Mike  Hanke  [26], 
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who  worked  in  close  cooperation  with  the  design  team  throughout  the  design  process.  Mr. 
Hanke’s  thesis  focused  on  the  decisions  regarding  the  C&DH  subsystem  and  its  initial 
development  and  integration.  His  work  is  considered  a  companion  study  to  the  SIMS  AT 
design.  The  following  paragraphs  highlight  the  evaluation  of  each  C&DH  subsystem  alter¬ 
native  against  the  values  specified  in  the  VSD. 

Total  Cost.  While  the  direct  control  solution  would  have  used  simple 
components,  the  sunk  costs  of  the  dSPACE  system  meant  the  visual,  digital  computer  so¬ 
lution  can  directly  compete  with  the  direct  control  solution.  The  analog  computer  solution 
was  expected  to  be  the  most  expensive  due  to  the  specialized  nature  of  the  technology.  The 
digital  (text)  solution  was  moderately  priced  because  the  equivalent  of  the  dSPACE  hard¬ 
ware  and  software  would  have  to  be  purchased;  they  are  common,  commercial  off-the-shelf 
components,  however. 

Total  Time.  The  digital  solution  was  considered  the  best  in  this 
category  because  the  parts  were  readily  available  and  would  take  less  time  to  arrive  and 
be  integrated  into  the  system.  The  dSPACE  system  (graphical)  required  the  least  amount 
of  time  since  most  of  the  parts  were  already  on  hand  at  AFIT.  The  direct  control  solution 
was  expected  to  take  about  as  long  as  the  digital  (text)  solution  because  both  would 
require  part  selections,  orders,  and  integration  troubleshooting.  The  analog  computer 
implementation  would  take  the  longest  because  it  is  unique,  the  order  time  would  be 
considerable,  and  the  integration  would  be  difficult,  because  of  limited  in-house  expertise 
available  for  troubleshooting. 

Number  of  Hazards.  The  digital  computer  solutions  were  ranked 
the  highest  because  the  assumption  was  that  much  of  the  implementation  would  be  based 
upon  previously  tested  “building  block”  solutions.  Also,  there  are  numerous  sources  for  all 
components  of  a  digital  computer  subsystem.  This  situation  was  not  the  case  for  the  other 
technologies:  the  direct  system  would  be  nearly  entirely  fabricated  at  AFIT  and  wbuld  not 
be  as  “tight”  as  mass-produced  commercial  component  solutions.  The  analog  computer 
solution  would  have  more  commercial  “building  blocks”  in  its  design,  but  would  require 
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more  fabricated  portions  than  the  digital  systems.  In-house  fabrication  could  increase  the 
potential  for  unforeseen  hazards. 

Hazard  Severity.  This  category  follows  the  same  logic  as  the 

number  of  hazards  -  the  more  commercial  building  blocks  used,  the  fewer  things  that  can 
fail  and  the  less  severe  the  potential  system  failures. 

Data  Capability.  The  digital  solutions  assume  the  data  can  be 
viewed  real-time  and  collected  directly  on  the  computer  hard  drive  or  use  typical  lab-quality 
data  acquisition  systems.  The  other  two  alternatives  assume  a  totally  independent  data¬ 
logging  system  that  would  allow  viewing  any  “user-friendly”  data  during  the  experiment; 
only  oscilloscope  traces  or  strip  charts  would  be  available  real-time. 

Ease  of  Use.  The  digital,  graphical  environment  is  generally  the 
most  intuitive  for  development  and  control.  Digital  computers  are  the  most  powerful 
due  to  the  current  tools  available  to  users.  Again,  lack  of  expertise  in  analog  computers 
would  make  system  or  payload  changes  a  significant  challenge;  the  possible  user  interfaces 
are  likely  to  be  similar  to  what  can  be  used  with  the  digital  (text  or  graphical)  class  of 
alternatives.  The  interface  and  adaptation  of  the  direct  control  would  be  the  least  favorable 
-  the  user  would  have  to  re-learn  how  to  handle  the  system  every  time  some  change  was 
made. 


Simulation  Fidelity.  Obviously,  the  direct  control  system  has  no 
simulation  capability  in  and  of  itself.  How  an  analog  computer-assisted  system  could  be 
simulated  (or  how  good  the  simulation  would  be)  was  unclear,  but  due  to  the  lack  of 
internal  expertise,  the  difficulty  of  developing  such  a  capability  would  be  great.  Digital 
simulations  are  well  understood  and  supported  with  numerous  software  tools.  A  visual 
environment  would  make  it  easiest  to  build  the  model.  Since  dSPACE  is  an  “integrated 
solution” ,  it  would  provide  the  highest  fidelity  model. 

Command  &  Control.  Any  human-in-the-loop  control  system  (i.e., 
the  direct  control  system)  is  very  difficult  to  deal  with,  and  its  responsiveness  would  be 
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user-dependent.  The  digital  control  systems  allow  the  SIMS  AT  to  perform  commands 
easier  (and  convert  to  an  autonomous  system)  due  to  the  maturity  and  availability  of 
development  tools  and  supporting  hardware.  The  dSPACE  solution  was  determined  to  be 
best  for  command  and  control  due  to  the  integrated  nature  of  the  hardware  and  software. 

Robustness .  Scores  in  this  category  are  correlated  to  the  command 

and  control  measure.  Again,  graphical  digital  solutions  appeared  to  handle  the  widest 
range  of  possible  applications. 

Angular  Capability .  Each  technology  has  similar  angular  capabil¬ 
ities  and  scored  the  same.  However,  each  technology  has  different  drawbacks.  The  direct 
solution  suffers  from  the  requirement  of  the  operator  to  know  how  to  operate  the  controls 
to  cause  SIMS AT  to  move  “fast”  and  stop  “fast”,  then  stay  “on  target.”  The  computer  so¬ 
lutions  all  suffer  from  the  added  weight  and  moment  of  inertia  caused  by  onboard  computer 
accessories. 

2.3.5  Communications.  Top-level  investigation  of  wireless  data  transfer 
methods  indicated  that  the  wireless  LAN  option  could  achieve  the  necessary  data  transfer 
rates  required  by  the  SIMS  AT  design.  Several  vendors  offered  wireless  LAN  systems  with 
advertised  data  rates  up  to  10Mbps  for  Ethernet  and  non-Ethernet  connections,  and  even 
greater  data  rates  for  FastEthernet  (or  similar)  solutions. 

System  modeling  of  the  flight  test  telemetry  system  alternative  was  based  on  mis¬ 
sile  flight  test  systems,  since  these  systems  also  require  compact,  lightweight  components. 
Because  these  telemetry  systems  are  generally  designed  for  range  applications;  the  trans¬ 
mission  power,  data  rates,  and  environmental  protection  (such  as  “high-g”  shock-proofing) 
were  overdesigned  for  the  SIMS  AT  laboratory  enviromnent.  Furthermore,  significant  RF 
concerns  existed  with  these  alternatives  since  broadcast  of  such  high-frequency  data  (typi¬ 
cally  UHF)  in  the  laboratory  environment  at  higher  transmission  powers  could  potentially 
cause  interference  with  other  electronic  equipment,  as  well  as  endanger  humans  in  the 
vicinity  of  the  system.  System  evaluations  for  the  flight  test  telemetry  systems  were  based 


2-28 


on  a  baseline  Aydin  Vector  6  missile  telemetry  system  [4].  The  following  paragraphs  use 
the  values  identified  in  Section  2.2.9  to  compare  the  flight  test  telemetry  alternative  to  the 
wireless  LAN  alternative. 

Total  Cost .  An  integrated  flight  test  telemetry  system  generally 

requires  the  use  of  a  command  encoder,  command  decoder,  dual  transmitters  and  receivers 
(or  transceivers),  telemetry  bus  monitoring  equipment,  and  data  formatting  equipment.  A 
typical  system  is  generally  in  excess  of  $10,000  as  a  minimum.  These  increased  costs 
are  due  to  the  number  of  components,  and  the  environmental  protection  necessary  for 
range  applications  7.  Wireless  LANs  are  relatively  inexpensive,  priced  from  $400  to  $3000 
depending  on  the  network  configuration  and  selected  vendor. 

Total  Time .  Wireless  LANs  are  commercially  available  and  built  to 
“plug-and-play” .  Assuming  a  network-compatible  data  collection  and  formatting  system 
is  in  place,  the  wireless  LAN  will  not  require  the  extensive  integration  efforts  typical  of  a 
flight  test  telemetry  system. 

Number  of  Hazards.  Typical  operating  voltages  for  a  wireless  LAN 
system  are  approximately  5V,  with  transmission  powers  on  the  order  of  50mW.  Conversely, 
the  flight  test  systems  are  built  to  the  aerospace  standard  of  28V,  and  incorporate  trans¬ 
mission  powers  from  2W  to  10W  for  range  applications.  The  higher  voltages  and  output 
powers  of  the  flight  test  systems  make  them  a  more  hazardous  alternative. 

Hazard  Severity.  Prolonged  exposure  to  transmission  powers  in 
the  2W  to  10W  range  may  be  dangerous  for  laboratory  personnel,  and  are  more  likely 
to  cause  interference  with  other  electronic  laboratory  equipment.  Permission  to  use  such 
systems  may  be  difficult  to  obtain  from  the  88th  Wing  at  Wright-Patterson  AFB. 

6  Aydin  Vector  is  one  of  four  divisions  of  the  Aydin  Corporation,  specializing  in  flight  test  instrumentation 
for  the  aerospace  industry.  Aydin  Vector  telemetry  systems  have  been  used  extensively  in  missile  flight  test 
applications,  to  include  the  Sidewinder,  Sparrow,  A  MR  A  AM,  Air-Launched  Cruise  Missile,  and  Advanced 
Cruise  Missile. 

Components  are  generally  built  to  withstand  100-g  shocks.  These  extremes  will  not  be  approached  in 
the  SIM  SAT  design. 
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Data  Capability .  The  flight  test  systems  have  a  robust  data  capa¬ 

bility,  and  are  designed  for  high  data  transfer  rates.  However,  the  digital,  graphical  control 
solution  (such  as  dSPACE),  generally  requires  a  10Mbps  data  rate,  so  that  higher  data 
rates  provide  no  real  performance  advantage.  Thus,  the  wireless  LAN  solution  satisfies 
data  requirements  equally. 

Ease  of  Use .  Neither  alternative  appeared  to  have  significant  ad¬ 

vantages  in  this  category. 

Simulation  Fidelity.  Again,  neither  alternative  appeared  to  have 
significant  advantages  in  this  category. 

Command  &  Control.  A  flight  test  vehicle  is  typically  designed 
to  operate  under  its  own  guidance  and  control  system.  Therefore,  flight  test  telemetry 
systems  use  only  a  few  commands  to  override  this  control;  generally  20  command  tones 
may  be  paired  and  transmitted  to  issue  commands.  These  commands  correspond  to  preset 
responses  built  into  the  vehicle  software  8.  The  wireless  LAN  solution,  coupled  with  the 
C&DH  digital  control,  allows  greater  command  and  control  flexibility  by  permitting  the 
issuance  of  specific  commands  that  need  not  be  built  into  the  onboard  software. 

Robustness.  Scores  in  this  category  are  correlated  to  the  command 
and  control  measure.  Again,  a  wireless  LAN /digital  control  solution  allows  greater  exper¬ 
imental  flexibility. 

Angular  Capability.  Neither  solution  appeared  to  have  a  marked 
effect  on  angular  capability  relative  to  one  another. 


Research  of  wireless  modems  showed  that  maximum  data  rates  of  9600  bps  are  the 
typical  industry  standard  at  this  time.  This  data  rate  would  severely  limit  the  real-time 


8For  example,  a  10/13  tone  pair  may  correspond  to  the  command  Roll  Clockwise ,  wherein  the  satellite 
would  perform  a  predetermined  roll  until  a  subsequent  command  is  issued.  The  ability  to  roll  at  an  arbitrary 
angular  velocity  or  to  an  arbitrary  angular  position  is  not  present. 
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data  transfer  between  the  ground  station  and  the  satellite.  However,  retention  of  the  wire¬ 
less  modem  alternative  was  practical  since  the  possibility  of  a  separate  data  link  for  remote 
control/spindown  may  be  required  in  more  detailed  design.  Furthermore,  the  dSPACE 
C&DH  system,  a  digital  computer  with  graphical  interface,  may  require  two  data  links, 
one  for  command/telemetry  data  and  one  for  visualization  of  satellite  motion  (which  may 
allow  use  of  a  wireless  modem  for  this  secondary  data  transfer). 

2.3.6  Structures.  At  this  stage  of  the  design,  no  formal  analysis  into 
the  structural  support  of  the  satellite  subsystems  was  undertaken.  However,  the  need 
to  minimize  the  overall  moment  of  inertia  about  body  axes  was  recognized  as  a  clear 
structural  design  goal.  Moment  of  inertia  is  closely  related  to  system  torque  requirements 
and  satellite  slewing  performance.  Once  subsystem  alternatives  were  chosen  for  further 
design,  analysis  of  the  structural  configuration  of  the  satellite  would  begin. 

2.4  Interpretation 

2.4-1  General.  The  Concept  Exploration  and  Definition  phase  made  several 
significant  steps  towards  the  design  of  an  up-and-running  satellite  simulation  system.  The 
problem  was  refined,  with  an  initial  list  of  needs  and  top-level  requirements  generated.  A 
top-level  value  system,  complete  with  value  hierarchy,  was  developed.  The  overall  system 
architecture  was  framed,  with  potential  subsystem  classes  considered  and  explored.  Finally, 
these  alternatives  were  compared  and  analyzed,  with  decisions  made  for  each  subsystem 
before  progressing  into  the  Preliminary  Design  phase. 

2.4.2  Alternatives  Summary.  In  general,  only  the  C&DH  setup  signifi¬ 
cantly  affected  the  overall  system  architecture  once  the  infeasible  and  impractical  subsys¬ 
tem  alternatives  were  removed.  As  stated  previously,  choice  of  C&DH  architecture  was 
necessary  to  advance  to  the  Preliminary  Design  phase.  As  the  analysis  showed,  the  domi¬ 
nant  solution  class  for  the  C&DH  was  the  digital  computer  with  graphical  interface.  This 
solution  was  also  favorable  due  to  the  sunk  costs  of  the  dSPACE  system  purchase. 
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For  the  AD  ACS  alternatives,  the  choice  of  IMUs  for  attitude  determination  was  made. 
Additionally,  momentum  exchange  methods  were  chosen  for  further  design  of  the  attitude 
control  system.  These  ADACS  alternatives  are  proven  methods  and  have  fewer  associated 
risks  in  terms  of  unforeseen  problems,  such  as  failure  to  meet  requirements  or  difficulty  in 
fabrication  and  integration.  The  use  of  gas  jets  (or  other  mass  expulsion  methods)  was 
retained  as  a  possible  means  for  slewing/braking  augmentation.  However,  gas  jets  alone 
were  determined  to  be  an  impractical  ADACS  solution.  The  choice  of  chemical  batteries 
for  the  power  subsystem  was  also  grounded  in  precedent.  Through  a  range  of  available 
types  and  sizes,  chemical  batteries  allow  flexibility  in  meeting  power  requirements,  quicker 
integration  schedules,  and  confidence  in  proper  operation. 

The  use  of  a  wireless  LAN/modem  architecture  was  determined  based  on  the  use  of  a 
digital  (graphical)  computer  C&DH  subsystem.  As  described  in  Section  2.3.5,  the  wireless 
LAN  solution  dominated  the  flight  test  telemetry  system  for  application  in  this  design, 
thereby  removing  the  choice  of  flight  test  telemetry  systems  from  further  consideration. 
The  C&DH  architecture,  namely  the  use  of  dSPACE  (or  similar),  suggested  the  use  of 
a  wireless  network,  and  allowed  for  possible  onboard  computer  processing.  An  in-depth 
investigation  of  onboard  versus  offboard  data  processing  was  left  to  the  Preliminary  Design 
phase. 

Regarding  the  structures  subsystem,  refinement  of  the  structural  configuration  was 
not  made  at  this  level  of  design.  Table  2.2  summarizes  the  results  of  the  Concept  Explo¬ 
ration  and  Definition  phase,  and  sets  the  stage  for  the  beginning  of  Preliminary  Design. 

Table  2.2  Concept  Exploration  and  Definition  Subsystems  Summary 


Subsystem 

Design  Choice 

ADACS 

IMUs/Momentum  Exchange 

Power 

Chemical  Batteries 

C&DH 

Digital  Computer  (Graphical) 

Communications 

Wireless  LAN/Modem 

Structures 

As  Required 
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III.  Preliminary  Design 

3. 1  Overview 

In  this  lifecycle  phase,  the  solution  classes  identified  in  Concept  Exploration  and 
Definition  were  further  refined.  Trade  studies,  research,  and  system  modeling  were  used  to 
determine  which  types  of  subsystems  best  met  the  cost-effectiveness  system  goals.  As  the 
Preliminary  Design  phase  progressed,  several  significant  decision  points  became  obvious 
before  the  design  could  progress  into  the  Detailed  Design  phase.  These  decision  points 
included  selection  of  a  C&DH  architecture,  as  well  as  the  momentum  exchange  method  for 
ADACS.  From  that  point,  development  of  control  laws,  enumeration  of  communications 
interfaces,  and  evaluation  of  system  power  requirements  could  begin  in  more  detail,  allow¬ 
ing  assessment  and  consideration  of  subsystem  alternatives.  The  emphasis  on  this  phase 
was  to  identify  one  solution  class  within  each  subsystem;  the  Detailed  Design  phase  could 
then  evaluate  system  alternatives  using  specific  choices  within  each  solution  class.  The 
waterfall  design  model  in  Figure  3.1  highlights  the  focus  of  this  chapter. 


Figure  3.1  Preliminary  Design  Activity 
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3. 2  Issue  Formulation 


3.2.1  Problem  Statement.  The  problem  statement  was  refined  and  nar¬ 
rowed  to  provide  a  more  specific  direction  to  the  Preliminary  Design  phase.  The  problem 
statement  was  summarized  as  follows: 

Incorporating  the  system  architecture  developed  in  the  Concept  Exploration  and  Def¬ 
inition  phase,  refine  the  subsystem  alternatives  within  each  solution  class  such  that  sub¬ 
system  requirements  are  identified,  subsystem  interfaces  are  recognized,  and  the  system 
architecture  is  developed  to  allow  detailed  design  and  system  integration  in  the  next  phase. 

3.2.2  Problem  Scope.  The  output  of  the  Concept  Exploration  and  Def¬ 
inition  phase  was  a  general  system  architecture,  to  include  individual  subsystem  classes 
within  this  architecture,  as  shown  in  Table  2.2.  The  goal  of  this  phase  was  to  determine 
the  best  subsystem  choice  within  each  subsystem  class,  and  to  investigate  the  subsystem 
interactions  and  develop  subsystem  requirements.  As  a  first  step  in  the  accomplishment 
of  these  goals,  the  system  architecture  developed  in  Concept  Exploration  and  Definition 
needed  to  be  enhanced  to  include  subsystem  interactions.  A  determination  of  the  most 
critical  subsystem  interactions  could  then  be  made.  Based  on  these  critical  interactions,  it 
could  then  be  determined  which  subsystem  choices  had  the  greatest  system  impacts.  These 
high-impact  decisions  could  then  be  made  at  the  system  level,  followed  by  determination 
of  other  subsystem  alternatives  as  necessary.  Decisions  which  need  not,  or  could  not,  be 
made  prior  to  Detailed  Design  were  identified  and  left  to  be  addressed  in  the  Detailed  De¬ 
sign  phase.  This  complete  iteration  through  the  Preliminary  Design  phase  was  completed 
by  mid-September  1998. 

3.2.3  Requirements  Refinement.  The  initial  needs  identified  in  the 
Concept  Exploration  and  Definition  phase  (see  Section  2.2.5)  were  further  defined  in  this 
phase,  as  summarized  below: 

•  System  must  support  experiments  of  30-60  minutes  duration. 

•  Frequency  of  interest  for  vibration  tests  is  approximately  250Hz. 

•  Sampling  speed  should  be  at  least  500Hz  (twice  the  frequency  of  interest). 
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•  Data  handling  system  should  support  32  input  and  32  output  channels. 

•  Slew  rate  should  be  maximized  within  safety  limits  in  the  three-axis  stabilized  con¬ 
figuration. 

•  Nominal  operating  slew  rate  is  10°/sec. 

•  Pointing  and  attitude  accuracy  error  should  not  exceed  0.005°. 

•  Payload  weight  is  approximately  100-135  lb. 

•  Payload  location  is  preferred  on  one  side,  with  capability  to  accommodate  two-sided 
experiments  with  minor  adjustments. 

•  Pure  and  dual  spin  configurations  are  necessary  for  demonstration  purposes  only. 

•  Mass  distribution  calculations  for  simulator  control  laws  will  be  handled  by  the  ex¬ 
perimenter,  but  the  system  should  be  user-friendly  to  accommodate  inertial  property 
inputs. 

•  Emergency  shutdown  of  the  system  should  allow  a  return  to  stable  configuration 
before  reserve  air  flow  is  depleted  (approximately  5  minutes). 

3.2.4  System  Functional  Layout.  As  a  starting  point  in  the  Preliminary 
Design  phase,  the  output  of  the  Concept  Exploration  and  Definition  phase  was  summarized 
and  refined.  The  construction  of  a  concept  map  assisted  in  the  identification  of  subsystem 
interactions,  and  aided  in  the  framework  of  a  functional  layout.  Figure  3.2  shows  this 
concept  map,  including  a  preliminary  delineation  of  onboard  and  offboard  functions. 

From  this  concept  map  and  the  system  architecture  developed  in  the  Concept  Explo¬ 
ration  and  Definition  phase,  the  functional  layout  shown  in  Figure  3.3  and  Figure  3.4  was 
developed.  This  functional  breakdown  allowed  further  insight  into  the  subsystem  interac¬ 
tions  and  flow  of  data.  Implicit  in  this  layout  is  the  location  of  the  controller  assembly 
on  the  ground  computer.  Initially,  the  use  of  the  digital,  graphical  C&DH  subsystem  was 
assumed  to  include  ground  processing  using  dSPACE  (or  similar)  software  loaded  onto 
the  ground  computer.  However,  additional  research  revealed  that  the  dSPACE  AutoBox 
DS400  system  may  provide  the  capability  for  onboard  processing  while  still  using  the 
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Figure  3.2  Preliminary  Design  Concept  Map  [26] 

dSPACE  graphical  interface  on  the  ground  computer  station1.  Other  onboard  processing 
alternatives  may  also  be  implemented  should  another  digital,  graphical  C&DH  subsystem 
have  been  used  in  favor  of  the  dSPACE  system.  Thus,  determination  of  onboard  versus 
offboard  processing  (or  a  combination)  was  identified  as  an  important  system  architecture 
decision  to  be  made  within  this  design  phase. 

‘The  AutoBox  was  initially  developed  for  use  in  automobile  testing  applications  in  a  wired  configuration 
with  a  personal  computer  loaded  with  dSPACE  software,  but  was  considered  for  use  on  SIMSATin  a  wireless 
configuration. 
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“GROUND”  FUNCTIONAL  LAYOUT 
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Input  desired  actions 
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Desired  Action 


COMMAND  ASSEMBLY 

Converts  desired  actions  into 
aduaf  commands,  incorporates 
command  library" 


CM  DR 


NOTATION: 

CMDR  =  desired  command  word 
CMDU  =  usable  command  data 
CMDD  =  digital  command  data 
CMDRF  -  xmitted  command  data 
TLMR  =  raw  telemetry  data 
TLMU  =  usable  telemetry  data 
TLMD  =  digital  telemetry  data 
TLMRF  =  xmitted  telemetry  data 
DISP  =  display  format  for  user 


DISP 


Figure  3.3  Offboard  Functional  Layout 
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“SATELLITE”  FUNCTIONAL  LAYOUT 


Figure  3.4  Onboard  Functional  Layout 


3.2.5  Preliminary  Design  Issues.  In  order  to  take  the  design  from 
the  Concept  Exploration  and  Definition  phase  into  the  Detailed  Design  phase,  key  issues 
needed  to  be  identified  and  resolved  within  the  Preliminary  Design  phase.  The  following 
system  decisions  were  identified  as  critical  to  this  stage  of  design: 

•  Specification  of  the  digital,  graphical  C&DH  software. 

•  Resolution  of  onboard  versus  offboard  data  processing  and  control. 

•  Selection  of  a  momentum  exchange  method  for  the  ADACS  subsystem. 

•  Selection  of  a  chemical  battery  type  for  the  power  subsystem. 

•  Determination  of  a  wireless  LAN  development  effort  or  commercial-off-the-shelf  (COTS) 
procurement. 

•  Determination  of  the  wireless  transmission  frequency  ranges. 

•  Identification  of  structural  considerations. 

The  following  paragraphs  describe  why  these  design  issues  were  important  at  this  stage  of 
system  development. 

3. 2. 5.1  C&DH  Software.  The  C&DH  architecture  was  a  critical  sub¬ 
system  decision  for  the  overall  system  design.  Choice  of  a  C&DH  software  solution  de¬ 
termined  the  signal  interfaces  between  all  other  subsystems,  as  well  as  the  experimental 
payload.  Since  the  C&DH  subsystem  is  responsible  for  command  entry  and  control  law 
manipulation,  it  is  also  critical  in  defining  the  user  interface.  As  stated  in  Section  2.2.11, 
the  communications  subsystem  is  highly  dependent  on  the  C&DH  architecture,  as  it  repre¬ 
sents  the  bridge  between  onboard  and  offboard  C&DH  functions  and  components.  Clearly, 
no  subsystem  design  was  immune  to  the  choice  of  C&DH  software.  Furthermore,  selection 
of  a  C&DH  software  package  allowed  the  initiation  of  control  law  software  development. 

3. 2. 5. 2  Onboard  vs.  Offboard  Processing.  The  question  of  onboard 
versus  offboard  data  processing  and  simulator  control  needed  to  be  addressed  before  de¬ 
tailed  subsystem  design.  In  addition  to  the  obvious  impact  on  the  communication  system, 
the  location  of  control  law  processing  greatly  influences  the  satellite’s  physical  design. 
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Onboard  processing  would  include  the  volumetric  and  weight  penalties  of  the  associated 
processing  hardware,  and  also  increase  the  power  requirements  onboard  the  vehicle.  Vol¬ 
umetric  and  weight  penalties  not  only  impact  the  experimenter’s  usable  payload  margin, 
but  also  impact  the  requirements  of  the  ADACS  subsystem.  Thus,  the  system  architec¬ 
ture  is  highly  dependent  on  location  of  the  processing  hardware,  whether  that  be  onboard, 
ofiboard,  or  a  combination  thereof. 

3. 2. 5. 3  Selection  of  Momentum  Exchange  Method.  As  described 
in  Section  2.4.2,  the  attitude  control  function  was  narrowed  down  to  momentum  exchange 
methods  in  the  Concept  Exploration  and  Definition  phase.  Within  the  momentum  ex¬ 
change  solution  class,  the  CMGs  alternative  differed  considerably  from  the  momentum 
wheel  alternative,  therefore  a  decision  between  the  two  was  critical  to  continued  system 
design.  Once  this  decision  was  made,  the  development  of  control  laws,  identification  of 
ADACS  signal  specifications,  estimation  of  onboard  power  requirements,  and  definition  of 
the  physical  configuration  could  be  accomplished  in  the  next  design  phase. 

3. 2. 5. 4  Chemical  Battery  Types.  Because  some  alternatives  within  the 
chemical  battery  solution  class  fall  under  strict  hazardous  material  guidelines,  identification 
of  a  preferred  chemical  battery  type  in  this  design  phase  would  allow  lead  time  to  seek  and 
acquire  approval  for  use  of  hazardous  materials  as  necessary.  Furthermore,  due  to  the  wide 
variety  of  sizes,  voltages,  and  discharge  characteristics,  the  choice  of  a  preferred  battery 
type  reduced  the  solution  space  and  allowed  more  detailed  comparisons  in  the  next  design 
phase. 


3. 2.5. 5  Wireless  LAN  Design.  The  use  of  wireless  LAN  in  the  SIM- 
SAT  design  is  a  new,  and  relatively  unique,  application  for  wireless  LAN  technology.  A 
custom-developed  wireless  LAN  system  using  in-house  or  commercially-developed  wire¬ 
less  technologies  may  encounter  unforeseen  challenges  and  become  a  significant  and  pro¬ 
tracted  design  effort  in  and  of  itself.  Therefore,  determination  of  whether  to  pursue  a 
custom-developed  wireless  LAN  architecture  or  instead  incorporate  a  COTS  solution  was 
important  at  this  stage  of  the  design. 
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3. 2. 5. 6  Wireless  Frequency  Range.  Since  base  approval  is  required 
for  use  of  RF  technologies  on  Wright-Patterson  AFB,  identification  of  the  probable  wireless 
frequency  ranges  was  necessary  to  begin  the  process  of  acquiring  this  approval. 

3.2.5. 7  Structural  Considerations.  At  this  stage,  detailed  develop¬ 
ment  of  a  structural  subsystem  was  not  necessary.  Based  on  the  other  subsystem  alterna¬ 
tives,  investigation  of  the  structural  configuration  on  a  system  level  could  be  accomplished 
within  the  Detailed  Design  phase.  However,  it  was  important  to  the  continued  design 
to  ensure  that  structural  considerations  were  addressed  at  this  stage  such  that  no  criti¬ 
cal  structural  issues  were  overlooked  and  the  results  of  the  Preliminary  Design  remained 
structurally  feasible. 

3.2.6  Additional  Actors.  In  addition  to  the  actors  identified  in  the  Con¬ 
cept  Exploration  and  Definition  phase,  the  following  actors  were  identified  as  significant 
at  this  stage  of  design: 

AFIT  Computer  Support.  This  office  (AFIT/SC)  provided  technical  support  and  ex¬ 
pertise  needed  to  upgrade,  acquire,  and  install  the  computers  needed  to  operate 
the  SIMSAT  system,  as  well  as  be  used  by  the  team  in  the  design  process.  Fur¬ 
thermore,  AFIT/SC  provided  the  frequency  management  authority  through  which 
wireless  communication  issues  must  be  coordinated. 

AFIT  Fabrication  Shop.  The  fabrication  shop  was  needed  to  discuss  structural  consid¬ 
erations,  momentum  wheel  designs,  and  other  construction  issues.  Although  pro¬ 
duction  specifications  were  not  a  goal  of  this  design  phase,  the  fabrication  shop  was 
involved  early  in  the  process  to  ensure  that  critical  design  issues  were  not  overlooked. 

Laboratory  Technicians.  The  AFIT  technicians  were  also  included  early  in  the  design 
process  to  prevent  overlook  of  critical  issues,  ensure  they  were  familiarized  with 
background  design  information,  and  gain  design  insights  based  on  their  laboratory 
expertise. 
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3.2.7  Value  System  Design.  For  this  level  of  design,  the  value  system 
constructed  in  the  Concept  Exploration  and  Definition  phase  was  expanded  to  include 
quantitative  measurables  allowing  more  detailed  system  comparisons.  The  fundamental 
values  identified  in  the  initial  VSD  -  cost,  performance,  and  safety  -  were  retained  in 
this  next  iteration  of  the  value  system,  except  that  the  schedule-related  measures  under 
the  cost  heading  were  placed  under  the  added  system  objective  of  schedule  minimization. 
This  division  allowed  cost  and  schedule  to  be  traded  and  weighted  more  independently. 
Figure  3.5  shows  the  system-level  objectives  hierarchy.  The  fundamental  values  of  cost, 
schedule,  performance,  and  safety  are  divided  into  lower-level  evaluation  considerations, 
which  are  evaluated  using  associated  measurables  (also  called  metrics ).  The  24  metrics  are 
described  in  the  following  sections  corresponding  to  the  fundamental  values.  Appendix  A 
describes  each  metric  in  further  detail. 

3. 2.7.1  Cost.  This  value  was  assessed  based  on  both  Capital  Costs  (the 
costs  to  get  the  system  up  and  running)  and  Operations  and  Maintenance  (O&M)  Costs 
(the  costs  to  keep  the  system  up  and  running).  Capital  costs  were  measured  in  $,  whereas 
O&M  costs  were  measured  in  $/year. 

3. 2.7. 2  Schedule.  This  value  was  assessed  using  the  single  metric  of 
total  delivery  weeks.  Total  Delivery  Weeks  included  the  time  required  to  order  components, 
build  components,  deliver  components,  and  integrate  components  into  the  system.  Detailed 
testing  and  evaluation  of  components  (beyond  integration  testing)  was  not  included  in  this 
schedule  metric. 

3. 2.7. 3  Safety.  Two  evaluation  considerations  were  assessed  for  this 
value:  equipment  damage  and  personnel  risk.  Equipment  damage  was  quantified  using 
a  Relative  Damage  Index ,  which  combined  the  probability  of  failures  with  the  estimated 
damage  due  to  failures.  Likewise,  personnel  risk  was  quantified  using  a  Relative  Injury 
Index ,  which  combined  the  probability  of  mishaps  with  the  estimated  injury  due  to  mishaps. 
These  indices  are  described  more  fully  in  Appendix  A,  page  A-5. 
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3. 2.7.4  Performance.  This  category  required  the  most  elaboration 
in  order  to  quantify  all  the  values  important  to  the  overall  system  performance.  The 
fundamental  value  of  performance  was  divided  into  three  second-tier  values:  Execution , 
Robustness,  and  Ease  of  Use.  Evaluation  considerations  and  associated  measurables  for 
each  of  these  second-tier  values  are  described  in  the  following  paragraphs. 

Execution.  Execution  refers  to  the  ability  of  the  system  to  perform  an  experiment  it 
has  been  fitted  to  accommodate.  The  following  list  of  evaluation  considerations  and 
associated  measurables  was  used  to  assess  this  value. 

•  Controllability.  The  communication  and  control  aspects  of  performance  were 
considered  within  this  category. 

-  Processor  Schedulability  Analysis.  This  measure  quantified  the  support  for 
Rate  Monotonic  Analysis  (RMA)  by  the  system.  RMA  and  other  schedu¬ 
lability  techniques  are  described  in  detail  in  the  companion  thesis  of  Mr. 
Hanke  [26:3-5-3-9].  RMA  support  was  categorized  by  the  following  levels: 
none,  unsupported,  moderate,  or  full. 

-  Communications  Latency.  This  measure  quantified  the  delay  from  sensor 
to  processor  to  effector.  This  delay  is  the  time  involved  in  the  gathering 
of  telemetry,  processing  and  transmission  of  telemetry,  execution  of  con¬ 
trol  software,  transmission  of  updated  commands,  and  reception  of  these 
commands  by  control  elements. 

-  Bandwidth  Requirement.  The  bandwidth  required  to  maintain  communica¬ 
tion  and  control  of  the  satellite  was  represented  by  this  measure. 

•  Data  Capability.  Collection  and  real-time  representation  of  data  were  con¬ 
sidered  within  this  category. 

-  Post-Mission  Data  Analysis.  This  binary  (yes/no)  measure  indicated  whether 
data  can  be  stored  for  post-mission  playback. 

-  Real-Time  Data.  This  binary  (yes/no)  measure  indicated  whether  data  can 
be  viewed  real-time  as  an  experiment  is  conducted. 
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•  Satellite  Movement.  This  category  described  the  system’s  movement  capa¬ 
bilities. 

-  Slew  Rate  Sensing.  This  measure  referred  to  the  slew  rate  range  of  the 
sensing  equipment.  Sensors  are  generally  rated  to  be  accurate  only  within 
a  range  of  slew  rates  (for  example,  an  IMU  may  be  designed  for  accurate 
operation  from  0°/sec  to  60° /sec). 

—  Rate  Sensing  Accuracy.  The  rate  accuracy  of  the  system’s  sensors  (mea¬ 
sured  in  deg/sec)  was  quantified. 

-  Slew  Capability.  This  measure  used  the  torque  generation  ability  and  mo¬ 
ments  of  inertia  of  the  system  to  determine  slew  capability,  which  is  the 
degrees  (or  radians)  of  slew  in  a  given  amount  of  time. 

Robustness.  Robustness  refers  to  the  ability  of  the  system  to  support  a  variety  of  exper¬ 
iments.  The  following  list  of  evaluation  considerations  and  associated  measurables 
was  used  to  assess  this  value. 

•  Range  of  Experiments.  The  interface  capability  to  perform  varied  experi¬ 
ments  was  considered  within  this  category. 

—  Interface  Modularity.  This  measure  quantified  the  ease  of  installing  and  re¬ 
arranging  experimental  hardware.  This  modularity  was  measured  in  terms 
of  the  percentage  of  components/subsystems  that  must  be  relocated  or  re¬ 
moved  in  order  to  accommodate  a  baseline  experiment. 

-  Experiment  Types.  The  number  of  experiment  types  (requested  by  the  cus¬ 
tomer)  which  are  supported  by  the  system  were  quantified  by  this  measure. 

•  Available  Margins.  The  system  margins  reserved  for  experiment  payloads 
were  considered  within  this  category. 

—  Mass  Margin.  The  mass  margin  (measured  in  kg)  is  the  additional  mass  the 
air-bearing/compressor  assembly  can  support  after  accounting  for  the  mass 
of  the  base  system.  Thus,  this  measure  quantified  the  maximum  payload 
mass  supportable  by  the  system. 
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—  Power  Margin.  The  power  margin  (measured  in  W)  is  the  excess  power  pro¬ 
vided  by  the  onboard  SIMS  AT  power  supply  after  accounting  for  the  base 
system  power  requirements.  Thus,  this  measure  quantified  the  maximum 
payload  power  consumption  supportable  by  the  system. 

Ease  of  Use.  Ease  of  Use  refers  to  the  ease  with  which  the  system  can  be  operated.  The 
following  list  of  evaluation  considerations  and  associated  measurables  was  used  to 
assess  this  value. 

•  Ground  Station  Capability.  The  capabilities  and  user-friendliness  of  the 
“ground  station”  environment  were  considered  within  this  category. 

—  Control  System  Analysis.  This  measure  assessed  the  ability  of  the  system  to 
easily  implement  system  changes  (due  to  experimental  configuration)  and 
validate  system  control  stability.  The  percentage  of  system  components  de¬ 
fined  by  the  ground  station  control  software  (i.e.,  all  control-related  prop¬ 
erties  can  be  easily  entered  and  evaluated  for  each  component)  was  used  as 
a  quantitative  measure. 

—  Development  Environment.  This  measure  assessed  the  ease  of  programming 
system  control  laws  based  on  the  type  of  programming  user  interface:  text, 
graphical,  or  object-oriented. 

—  Motion  Simulation.  This  binary  (yes/no)  measure  indicated  the  capability 
of  the  system  to  model  and  predict  satellite  behavior  before  actual  operation 
of  an  experiment. 

•  Command  and  Control.  The  ease  with  which  the  system  can  be  controlled 
during  operation  was  evaluated  by  this  category. 

-  User  Interface.  The  intuitive  nature  of  the  user  interface  was  measured 
as  the  percentage  of  the  displays /controls  presented  in  a  graphical ‘(visual) 
manner. 
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—  Command  Capability.  The  satellite/experiment  activities  controllable  from 
the  ground  station  were  categorized  by  this  measure  as  the  following:  ex¬ 
periment  start/stop  only,  AD  ACS  control,  or  ADACS  and  payload  control. 

•  O&M  Time.  This  category  described  the  time  required  to  configure,  maintain, 
and  alter  the  system  in  preparation  for  operation. 

—  Maintenance  and  Test  Time.  This  measure  quantified  the  time  required  to 
install  an  experiment  payload  and  validate  the  system  for  operation. 

—  Turn-Around  Time.  Assuming  an  experiment  has  been  installed  and  tested, 
the  turn-around  time  between  like  experiments  is  quantified  by  this  mea¬ 
sure.  In  general,  the  turn-around  time  is  reflected  by  the  time  spent  chang¬ 
ing  batteries.  Thus,  the  numbers  of  necessary  battery  swaps  and  spare 
batteries  were  considered  by  this  measure. 

3.2.8  Determination  of  C&DH  Software.  As  described  previously, 
determination  of  the  C&DH  software  was  a  major  design  issue  to  be  resolved  within  this 
lifecycle  phase.  The  thesis  work  of  Mr.  Hanke  specifically  addressed  this  issue.  Chapter  III 
of  his  thesis  evaluated  candidate  vendors  of  the  digital  control  C&DH  system,  which  was 
the  solution  class  chosen  in  the  Concept  Exploration  and  Definition  phase  [26:3-1-3-18]. 

The  same  problem-solving  process  (i.e.,  issue  formulation,  analysis,  and  interpreta¬ 
tion)  was  used  to  determine  the  best  choice  for  the  C&DH  software.  The  value  system 
shown  in  Figure  3.5  provided  the  objective  hierarchy  needed  to  choose  amongst  the  C&DH 
candidates.  Three  candidate  solutions  were  considered:  the  dSPACE  software,  as  well 
as  Matrix*  2  software  and  a  “piece-part”  solution.  The  “piece-part”  solution  involves 
searching  for  and  acquiring  the  necessary  components  to  develop  a  digital  control  C&DH 
package,  to  include  software,  electronic  components,  and  other  supporting  hardware.  [26:3- 

13] 

integrated  Systems,  Inc.,  produces  an  entire  range  of  products,  including  Matrix*,  to  support 
aerospace  and  automotive  control  applications. 
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Qualitative  analysis  between  these  three  candidate  solutions  showed  the  dSPACE 
solution  to  be  a  clearly  dominant  choice  [26:3-17].  As  far  as  cost,  the  dSPACE  solution 
was  far  superior,  since  the  system  was  acquired  before  the  SIMS  AT  design  effort  began 
and  its  associated  costs  were  unrecoverable.  Although  an  opportunity  cost  exists  if  the 
dSPACE  system  is  not  available  for  use  on  another  AFIT  project,  its  intended  use  was  for 
this  design  and  this  opportunity  cost  was  considered  marginal.  Even  discounting  this  cost 
advantage  of  the  dSPACE  solution,  it  was  still  equal  or  better  than  the  other  two  solutions 
in  each  value  category.  Thus,  detailed  quantitative  analysis  was  unnecessary  to  distinguish 
amongst  these  C&DH  candidates. 

With  the  dSPACE  solution  chosen  as  the  preferred  C&DH  software,  further  devel¬ 
opment  of  the  C&DH  architecture,  namely  onboard  versus  offboard  processing,  could  be 
accomplished  within  this  phase  using  dSPACE  as  a  constraint.  3 

3.2.9  System  Synthesis.  Each  subsystem  solution  class  was  expanded  to 
narrow  the  design  and  address  the  Preliminary  Design  issues  of  Section  3.2.5. 

3. 2. 9. 1  ADA  CS.  Within  the  solution  class  of  momentum  exchange  meth¬ 
ods  for  the  attitude  control  function,  there  were  two  subsystem  candidates:  momentum 
wheels  and  control  moment  gyros  (CMGs).  The  use  of  thrusters  to  augment  these  can¬ 
didates  was  retained  for  further  evaluation.  For  a  three-axis  stabilized  configuration,  if 
thrusters  were  needed  to  provide  adequate  slew  rates,  they  would  be  accounted  for  in  the 
system  modeling.  If  thrusters  were  only  needed  for  demonstration  experiments,  they  would 
not  be  included  in  the  system  comparisons  of  this  phase  since  demonstration  experiments 
required  less  emphasis  on  slew  performance.  Regarding  attitude  determination,  only  rate 
gyros  (with  or  without  accelerometers,  depending  on  the  model)  were  considered  for  fur¬ 
ther  investigation.  Position  sensors,  whether  onboard  or  external,  were  not  considered  at 
this  stage  of  the  design. 

3The  iterative  nature  of  the  systems  engineering  process  is  exemplified  by  the  issue  formulation  *  analysis, 
and  interpretation  steps  of  the  C&DH  software  subproblem  conducted  within  the  issue  formulation  step  of 
the  Preliminary  Design  problem. 
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3. 2. 9. 2  Power.  The  first  decision  regarding  chemical  batteries  was 
whether  to  use  primary  or  secondary  battery  types.  Primary  batteries  are  designed  for 
long  storage  life  and  low  power  density,  whereas  secondary  batteries  are  intended  for  mul¬ 
tiple  recharges,  thereby  reducing  system  lifecycle  costs.  Due  to  the  repetitive  nature  of 
the  experimentation  intended  for  SIMS  AT,  secondary  batteries  were  the  preferred  option. 
Thus,  only  rechargeable  batteries  were  considered. 

Several  chemical  battery  classes  were  identified,  to  include  lead  acid,  nickel  cadmium, 
zinc/silver  oxide,  cadmium/silver  oxide,  manganese  dioxide,  and  lithium.  Adherence  to 
AFIT  hazardous  material  regulations4  prevented  the  use  of  lithium  batteries,  thus  making 
that  choice  infeasible.  Each  of  the  other  chemical  battery  classes  was  retained  for  system 
modeling  and  analysis. 

In  addition  to  the  type  of  battery,  the  configuration  of  batteries  was  initially  consid¬ 
ered  in  this  design  phase.  Battery  configuration  was  divided  into  two  classes:  distributed 
power  system  and  single-source  power  system.  The  rationale  to  divide  the  power  configu¬ 
ration  into  these  classes  was  that  a  single-source  power  system  would  require  a  less  compli¬ 
cated  electrical  structure  to  provide  the  necessary  bus  operating  voltage.  However,  it  was 
determined  that  the  single-source  system  was  not  significantly  different  than  a  distributed 
battery  system.  In  fact,  the  simplicity  of  a  single-source  system  would  be  compromised  by 
the  necessity  to  use  voltage  dividers  to  provide  differing  operating  voltages  for  the  various 
subsystems  and  payload.  Furthermore,  there  was  no  need  at  this  stage  of  design  to  specify 
the  battery  configuration  since  the  choice  of  other  subsystems  would  drive  the  amount  of 
power  required. 


3. 2.9. 3  C&DH  .  Given  that  dSPACE  software  was  the  preferred  C&DH 
solution  class,  determination  of  onboard  versus  offboard  processing  was  the  next  major 
C&DH  issue  to  be  resolved  within  this  phase.  A  top-level  consideration  of  alternatives 
yielded  two  prominent  solutions:  (1)  install  an  AutoBox  on  the  satellite  to  house  the  pro¬ 
cessor  and  data  acquisition  boards  in  a  self-contained,  power-conditioned,  shock-mounted 

4AFIT  hazardous  material  guidelines  were  identified  as  a  constraint  in  the  Concept  Exploration  and 
Definition  phase. 
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enclosure,  or  (2)  pass  all  signals  (from  sensors  and  effectors5  onboard  the  satellite,  as  well 
as  commands  from  the  ground)  to  and  from  the  ground  station.  Shown  in  Figure  3.6,  the 
AutoBox  was  designed  with  an  integrated  Ethernet  card  to  send  the  10Mbps  data  stream 
to  a  computer  equipped  with  the  dSPACE  interface  software.  Within  these  two  major 
classes,  location  of  control  law  execution  still  needed  to  be  designated. 


Figure  3.6  AutoBox  DS400 

Before  more  explicit  definition  of  the  C&DH  alternatives  could  be  made,  the  potential 
tasks  required  of  the  C&DH  system  needed  to  be  further  defined  and  categorized.  These 
task  sets  are  described  in  the  following  paragraphs  and  pictorially  shown  in  Figure  3.7 
[26]. 


•  Attitude  Determination  and  Control.  This  task  set  includes  the  evaluation  of 
user  commands,  collection  of  satellite  telemetry,  determination  of  satellite  status, 
and  execution  of  satellite  control  laws.  This  task  set  is  henceforth  abbreviated  as 
“  ADAC” .  Control  of  satellite  functions  outside  of  the  AD  ACS  function,  but  not  a 
part  of  the  experiment  payload,  is  included  in  this  task  set. 

5  Those  elements  which  cause  an  action  are  referred  to  as  effectors . 


3-18 


•  Experiment  Control.  This  task  set  includes  evaluation  of  user  commands  spe¬ 
cific  to  the  experiment  payload,  collection  of  experiment  telemetry,  determination  of 
experiment  status,  and  control  of  the  experiment.  This  task  set  is  labeled  “EXP”. 

•  User  Interface.  This  task  set  composes  the  capability  to  provide  the  command 
authority  and  display  relevant  information  to  the  user. 
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Figure  3.7  Real-Time  Software  Architecture  [26] 

The  use  of  separate  processors  was  considered  for  these  task  sets.  Optimal  control 
law  execution  requires  minimization  of  the  delay  in  measurement  data  induced  by  signal 
transmission.  Thus,  for  control  functions  and  measurement  functions  to  be  on  separate 
processors,  communications  between  these  processors  must  be  low  delay,  as  well  as  able  to 
handle  large  data  volume.  It  was  determined  that  a  wireless  solution  may  not  adequately 
support  control  law  execution  using  separate  processors  [26:4-17].  However,  communica¬ 
tions  requirements  between  the  experiment  payload  and  the  satellite  AD  ACS  were  expected 
to  be  low  enough  that  separation  of  these  task  sets  on  separate  processors  would  be  feasible 
[26:4-17]. 
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The  use  of  multiple  processors  for  a  given  task  set  was  also  considered.  However,  the 
dSPACE  system  already  included  one  processor  board,  and  the  purchase  and  integration 
of  multiple  processor  boards  was  considered  to  provide  little  value  for  this  design  effort 
based  on  baseline  data  processing  requirements.  It  was  left  to  future  design  work  to  inves¬ 
tigate  and  implement  a  multi-processor  dSPACE  solution  if  data  processing  needs  should 
so  require.  As  stated  previously,  the  baseline  design  could  be  improved  to  better  handle 
specific  experiments  once  those  experimental  requirements  are  defined.  The  dSPACE  soft¬ 
ware  is  designed  to  handle  the  addition  of  multiple  processor  boards,  thereby  allowing  a 
multi-processing  upgrade  without  extensive  system  reconfiguration. 

An  additional  C&DH  processing  consideration  needed  to  be  addressed  should  a 
ground-based  processing  option  be  chosen:  how  to  transmit  sensor  and  effector  signals 
to  the  ground.  Two  methods  were  considered  to  format  data  suitable  to  wireless  transmis¬ 
sion.  Firstly,  the  AutoBox  could  be  used  strictly  for  signal  consolidation  (without  onboard 
processing  cards).  Secondly,  an  alternative  COTS  solution  could  be  designed/selected  for 
signal  consolidation.  [26] 

In  summary,  the  following  C&DH  task  allocations  were  defined  and  considered  for 
modeling  and  analysis  within  this  design  phase: 

•  All  Onboard  Processing.  This  alternative  includes  all  ADAC  and  EXP  processing 
onboard  the  satellite  using  dSPACE’s  AutoBox  solution. 

•  Split  Processing.  This  alternative  locates  the  ADAC  processing  on  the  ground 
computer  using  dSPACE  software,  with  the  EXP  processing  onboard  using  user- 
provided  processing  capability. 

•  Offboard  Processing  with  AutoBox.  All  tasks  using  this  alternative  are  executed 
on  the  ground  computer  using  dSPACE  software,  with  the  AutoBox  providing  signal 
consolidation. 

•  Offboard  Processing  without  AutoBox.  All  tasks  using  this  alternative  are 
executed  on  the  ground  computer  using  dSPACE  software,  with  a  COTS  solution 
providing  signal  consolidation. 
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3. 2. 9. 4  Communications.  In  order  to  provide  the  wireless  link  to  the 
dSPACE  software  on  the  ground,  several  communications  alternatives  were  considered. 
The  first  issue  addressed  was  the  overall  degree  of  the  communications  design  effort;  in 
short,  whether  to  develop  a  custom-designed  wireless  solution  or  procure  a  COTS  solution. 
A  custom  system  would  require  more  expertise  in  the  integration  and  testing  phase,  but 
may  provide  for  more  optimal  performance.  The  second  communications  issue  focused  on 
the  expected  frequency  ranges  to  be  used  in  the  SIMS  AT  design,  such  that  base  approval 
could  be  obtained  in  time  to  integrate  the  wireless  communications  system  with  the  other 
subsystems.  However,  since  the  solution  class  was  narrowed  to  wireless  LAN/modem 
technologies,  the  AFIT  frequency  manager  determined  that  base  approval  would  not  be 
difficult  to  obtain,  so  long  as  operating  powers  were  restricted  to  common  indoor  ranges. 
Thus,  identification  of  the  communications  frequency  was  not  critical  at  this  stage  of 
design.  The  following  two  alternatives  for  communications  were  considered  in  this  phase: 
custom-designed  wireless  LAN  and  COTS  wireless  LAN. 

With  the  dSPACE  software  already  selected,  the  use  of  a  wireless  modem  to  transfer 
RealMotion  data  was  retained.  RealMotion  is  a  three-dimensional  animation  tool, 
provided  by  dSPACE,  ideally  suited  to  simulation  applications.  RealMotion  requires  a 
separate  station  to  view  simulation  animations  in  real-time  (or  offline),  and  also  requires 
a  separate  data  stream  directly  from  the  processor  board  controlling  the  simulation.  At 
this  stage  of  the  design,  a  choice  of  wireless  modem  for  this  separate  data  stream  was  not 
necessary,  but  its  incorporation  into  the  design  was  accounted  for. 

3. 2.9. 5  Structures.  Although  a  structural  configuration  was  not  chosen 
at  this  stage  of  the  design,  it  was  important  to  begin  considering  the  system  layout  in  order 
to  ensure  that  subsystems  remained  feasible,  to  communicate  the  design  to  others,  and  to 
set  the  stage  for  detailed  structural  design  in  the  next  design  phase.  The  following  list 
of  considerations,  based  on  objectives  already  identified  in  the  value  system  design,  were 
identified  as  important  in  the  structural  design: 

•  Minimize  moments  of  inertia  to  allow  better  slew  rate  performance. 

•  Minimize  structural  weight. 
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•  Maximize  structural  rigidity  to  prevent  resonant  frequency  oscillations. 

•  Maximize  structural  modularity  to  accommodate  easy  and  quick  configuration  changes. 

•  Maximize  safety  by  enclosing  components  which  can  cause  serious  injury  or  damage 

should  they  catastrophically  fail. 

Two  structural  alternatives  were  identified  in  this  stage  as  baseline  ideas  for  future 
structural  development.  These  alternatives  were  classified  as  the  “milkcrate”  and  “wedding 
cake”  configurations6.  The  milkcrate  configuration  referred  to  a  boxed  truss  structure  on 
each  side  of  the  air  bearing  assembly.  Within  each  box  structure,  components  would  be 
housed  on  shelves  or  using  cross  members.  This  concept  differed  from  the  wedding  cake, 
which  was  named  for  its  progressive  layered  structure.  In  this  configuration,  plates  would 
be  stacked  on  each  side  of  the  air  bearing  assembly  (similar  to  a  barbell  with  weight  plates). 
Components  would  be  affixed  to  these  plates.  The  milkcrate  and  wedding  cake  structures 
were  not  directly  evaluated  at  this  stage  of  design,  but  were  useful  in  later  development  of 
the  structural  design. 

3. 2. 9. 6  Alternatives  Summary.  The  alternatives  designated  for  fur¬ 
ther  modeling  and  analysis  in  this  design  phase  are  shown  in  Table  3.1. 

3.3  Analysis 

3*3.1  System  Modeling .  At  this  stage  of  the  design,  significant  use  of 
mental  modeling,  background  research,  engineering  estimates,  and  vendor  specifications 
were  used  to  evaluate  the  alternative  system  configurations. 

3.3.2  Preliminary  Analysis.  Using  the  subsystem  alternatives  shown  in 
Table  3.1,  80  system  alternatives  could  be  generated  (using  the  full  factorial  breakdown 
of  the  subsystem  combinations).  Before  analyzing  each  alternative  on  the  system  level, 
this  number  of  alternatives  was  reduced  through  preliminary  investigation  which  identified 

6 A  third  alternative,  referred  to  as  the  “sombrero”,  used  a  fixed  structure  joining  the  two  sides  of  the 
air  bearing  assembly,  but  was  rejected  from  consideration  since  it  would  prevent  full  freedom  in  the  roll 
axis. 
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Table  3.1  Preliminary  Design  Subsystem  Alternatives 


Subsystem 

Alternatives 

Attitude  Determination 

Rate  Gyros 

Attitude  Control 

Momentum  Wheels 

Control  Moment  Gyros 

Power 

Lead  Acid  Batteries 

Nickel  Cadmium  Batteries 
Zinc/Silver  Oxide  Batteries 
Cadmium/Silver  Oxide  Batteries 
Manganese  Dioxide  Batteries 

Command  & 

Data  Handling 

All  Onboard  Processing 

Split  Processing 

Offboard  Processing  with  AutoBox 
Oflboard  Processing  without  AutoBox 

Communications 

Custom-Designed  Wireless  LAN 

COTS  Wireless  LAN  j 

Structures 

As  Required 

infeasible  or  impractical  alternatives,  as  well  as  combined  alternatives  which  appeared 
similar  on  a  system  level  into  common  alternative  classes. 


3.3.2. 1  Control  Moment  Gyros.  Alternatives  incorporating  CMGs 
were  the  first  class  of  alternatives  to  be  eliminated  from  consideration.  Although  CMGs 
were  initially  considered  to  be  a  possible  solution  for  attitude  control,  in-depth  research 
revealed  that  only  space-rated  CMGs  were  commercially  available,  which  were  on  the  order 
of  hundreds  of  thousands  of  dollars  to  procure.  These  findings  made  space-rated  CMGs 
economically  infeasible.  The  possibility  of  using  CMGs  not  intended  for  space  application 
was  also  considered,  but  acquisition  or  development  of  this  alternative  was  not  practical 
in  the  time  scheduled  for  initial  SIMS  AT  design.  Follow-on  development  of  the  baseline 
design  could  incorporate  non-space  CMGs  through  joint  research  efforts  with  a  CMG 
manufacturer7  or  a  dedicated  development  effort. 

7The  use  of  SIMS  AT  in  cooperation  with  industry  was  considered  a  future  possibility.  Discarded,  or 
out-of-tolerance,  CMGs  could  potentially  be  acquired  through  such  an  effort. 
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3. 3. 2. 2  Wireless  LAN  Development.  The  practicality  of  a  custom- 
designed  wireless  LAN  system  was  considered  before  more  formal  system  evaluations  using 
this  subsystem  choice  were  made.  Investigation  into  wireless  LAN  technologies  showed 
two  potentially  promising  research  areas  for  wireless  LAN  applications:  use  of  lossless  data 
compression,  and  use  of  omnidirectional  IR  transceivers. 

Lossless  Data  Compression.  Lossless  data  compression  could 
enhance  a  wireless  LAN  system  with  relatively  low  bandwidth  capability  to  adequately 
handle  higher  communications  traffic.  Jung  and  Burleson  presented  a  real-time,  low-area, 
and  low-power  VLSI  lossless  data  compressor  which  was  claimed  to  provide  “sufficient  per¬ 
formance  for  all  current  and  most  foreseeable  future  wireless  LANs”  [30:27].  However,  the 
use  of  such  a  system  for  this  design  was  considered  impractical  for  a  number  of  reasons. 
For  one,  lossless  data  compression  hardware/software  solutions  were  not  yet  commercially 
available.  Thus,  in-house  expertise  would  be  required  to  develop  and  integrate  such  a  sys¬ 
tem.  This  development  effort  was  beyond  the  scope  of  this  project,  and  beyond  the  design 
team’s  area  of  expertise.  The  benefit  of  such  a  system  was  determined  to  be  relatively 
minor  anyway,  since  wireless  LAN  systems  were  commercially  available  at  10Mbps  data 
rates  (required  for  a  dSPACE/AutoBox  link)  with  adequate  bandwidth  and  comparable 
costs  to  lower  data  rate/bandwidth  systems.  Thus,  the  performance  gains  of  lossless  data 
compression  were  considered  to  be  more  than  offset  by  the  difficulty  in  developing  and 
integrating  such  a  system. 

Omnidirectional  IR.  Omnidirectional  IR  transceivers  were  also  con¬ 
sidered  for  use  on  SIMS  AT.  The  advantages  of  this  alternative  would  be  elimination  of  RF 
interference,  no  need  for  base  RF  approval,  and  most  importantly,  faster  data  rates  of¬ 
fered  by  IR  transmission.  This  technology  was  not  well-developed  and  presented  a  high 
feasibility  risk,  and  its  application  in  a  rotating  body  compounded  this  risk  since  omnidi¬ 
rectional  IR  depends  on  elimination  of  scatter  and  interference  through  software  logic.  If  a 
transceiver  is  in  motion  (as  it  would  be  on  the  satellite),  scatter  and  interference  patterns 
would  be  unsteady  and  difficult,  if  not  impossible,  to  manage.  In  short,  this  alternative 
was  considered  infeasible  for  this  design. 
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COTS  Wireless  LAN.  Because  of  the  short  design  schedule  and 
limited  background  of  the  design  team,  a  custom-designed  wireless  LAN  system  was  con¬ 
sidered  to  be  impractical  in  the  SIMS  AT  design.  With  COTS  wireless  systems  available, 
only  the  COTS  wireless  LAN  alternative  was  considered  in  further  Preliminary  Design 
system  evaluations. 


3. 3. 2. 3  Battery  Types.  The  battery  types  identified  in  the  system  syn¬ 
thesis  step  all  exhibited  similar  system-level  interactions  in  terms  of  voltages  and  currents 
(which  were  driven  by  power  requirements),  regardless  of  the  specific  chemical  used  in  the 
battery.  Furthermore,  delivery  times  were  relatively  similar  for  any  battery  type.  It  was  in 
the  areas  of  cost  and  battery  characteristics  where  the  different  battery  types  were  dissim¬ 
ilar.  Table  3.2,  from  [34:13-10],  lists  some  of  the  characteristics  of  the  different  chemical 
battery  types  compared  for  use  in  this  design. 

The  first  batteries  eliminated  from  consideration  were  the  NiCd  vented  plate  batter¬ 
ies.  Vented  batteries  are  not  designed  for  operation  at  arbitrary  configurations,  to  include 
inverted;  thus,  only  sealed  batteries  remained  an  option.  A  flat  discharge  profile  was  desired 
to  ensure  constant  discharge  from  the  batteries  during  operation,  making  the  zinc/silver 
oxide  and  cadmium /silver  oxide  batteries  less  desirable  due  to  their  double  plateau  dis¬ 
charge  profiles.  These  options  also  had  a  relatively  short  shelf  life  (1-3  years)  and  higher 
costs.  Thus,  these  battery  types  offered  no  significant  system  advantages.  Manganese 
dioxide  batteries  also  displayed  a  non-constant  discharge  profile,  as  well  as  a  low  battery 
capacity  per  battery,  measured  in  Amp-hours.  Battery  capacity  is  a  measure  of  a  bat¬ 
tery’s  ability  to  meet  system  power  requirements.  The  availability  and  price  of  manganese 
dioxide-based  batteries  were  also  drawbacks. 

Both  sealed  lead  acid  and  sealed  NiCd  batteries  were  readily  available  commercially, 
while  generally  satisfying  system  power  requirements.  Additionally,  both  types  benefit 
from  long  cycle  life  spans,  and  offered  numerous  sizes  and  models.  Sealed  lead  acid  batter¬ 
ies,  however,  provided  higher  battery  capacity  per  battery.  On  a  system  level,  this  higher 
battery  capacity  allowed  smaller  (or  fewer)  batteries,  resulting  in  system  mass  and  inertia 
savings.  Furthermore,  the  lead  acid  batteries  were  less  expensive.  Thus,  the  NiCd  sealed 
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Table  3.2 


Chemical  Battery  Characteristics 


Lead  Acid 
(stationary) 

Lead  Acid 
(portable) 

NiCd 

(vented 

pocket 

plate) 

NiCd 

(vented 

sintered 

plate) 

NiCd 

(sealed) 

Zinc/Silver 

Oxide 

Cadmium/ 

Silver 

Oxide 

MnOz 

Nominal  cell 
voltage 

2.0 

1.2 

1.2 

1.2 

1.5 

1.2 

1.5 

Energy  density 
(Wh/kg) 

10-20 

30 

20 

37 

30 

90 

55 

30 

Volume 

(Wh/L) 

80 

90 

60 

Flat 

Flat 

Very  Flat 

Very  Rat 

Double 

Plateau 

Double 

Plateau 

Sloping 

Moderately 

High 

High 

High 

High 

Moderate 
to  High 

High 

Moderate 
to  High 

Low 

Self- discharge 
rate  (%/mo) 

N/A 

4-8 

5 

10 

3 

3 

1 

18-25 

2-8 

8-25 

3-10 

2-5 

1-3 

2-3 

20-50 

Cycle  life 

N/A 

250-500 

500-1000 

500-2000 

300-700 

100-150 

150-600 

20-50 

High  discharge 
rate 

No 

No 

No 

No 

Battery 

capacity 

(Amp-hrs) 

0.9-35 

5-1300 

10-100 

0.5-10 

0-5 

Cost  ($/kWh) 

m 

200-500 

600-1000 

1000-3000 

800-1500 

1000-2000 
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battery  offered  no  significant  system  advantages,  and  the  sealed  lead  acid  batteries  were 
the  sole  remaining  alternative. 

3.3.3  Remaining  System  Alternatives.  After  the  preliminary  analysis, 
the  only  major  subsystem  decision  at  this  stage  left  unanswered  regarded  the  C&DH 
architecture.  The  momentum  wheels,  sealed  lead  acid  batteries,  and  COTS  wireless  LAN 
were  treated  as  system  constraints  for  the  next  iteration  of  the  design  process  within  the 
Preliminary  Design  phase.  Choice  of  C&DH  architecture  was  made  on  the  system  level, 
comparing  the  following  four  alternatives:  all  onboard  processing  (with  AutoBox),  split 
(onboard/offboard)  processing,  offboard  processing  with  AutoBox,  and  offboard  processing 
without  AutoBox.  These  alternative  configurations  were  abbreviated  as:  ALL-ON-SAT, 
SPLIT,  GRD  W/  ABX,  and  GRD  W/O  ABX. 

3.3.4  Analysis  Methodology.  The  purpose  of  the  following  analysis  was 
to  determine  actual  measures  ( raw  values )  for  the  objectives  identified  in  the  objective 
hierarchy  of  Figure  3.5  for  each  remaining  system  alternative.  Next,  these  raw  values 
were  converted  into  scaled  scores  using  a  standardized  utility  scale,  based  on  decision 
maker/customer  inputs.  A  confidence  factor  could  then  be  applied  to  account  for  the  level 
of  confidence  associated  with  the  measurable  raw  values,  resulting  in  rated  scores.  Because 
of  the  large  degree  of  mental  modeling  and  estimation  used  in  this  analysis,  the  use  of 
confidence  factors  as  derating  multipliers  needlessly  narrowed  the  scoring  differences  since 
most  all  the  raw  values  were  considered  to  be  of  a  similar  level  of  confidence.  Therefore, 
confidence  factors  were  not  used  in  this  analysis,  resulting  in  equivalency  of  rated  scores  and 
scaled  scores.  In  the  interpretation  step,  additional  inputs  from  the  decision  makers  were 
used  to  designate  weighting  factors  to  apply  to  the  objective  hierarchy,  and  a  system  score 
was  thereby  computed  for  each  alternative,  allowing  ranking  of  alternatives  and  selection 
of  a  preferred  alternative  by  the  decision  maker. 

3.3.5  Raw  Values.  Each  alternative  was  analyzed  to  determine  a  r£iw  value 
for  each  measurable  from  the  VSD.  The  resolution  of  a  raw  value  was  either  binary  (e.g., 
yes/no),  a  finite  number  of  classes  (e.g.,  low,  medium,  high),  or  continuous  real  numbers 
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(e.g.,  29.5,  34.5).  Resolution  was  dependent  on  the  measurable  considered8.  A  summary 
of  the  raw  data  collection  was  first  published  in  Appendix  B  of  Mr.  Hanke’s  thesis  [26]. 

3.3. 5.1  Cost.  Capital  Costs  and  O&M  Costs  were  determined  through 
summation  of  the  associated  costs  for  each  subsystem.  These  cost  estimates  were  based 
on  vendor  research,  as  well  as  mental  modeling  of  relative  support  and  integration  costs. 
The  costs  associated  with  the  purchase  of  the  air-bearing  assembly  and  dSPACE  ground 
station  were  not  included,  as  these  purchases  were  already  completed  at  this  stage  of  the 
design.  Cost  estimates  are  tabulated  in  Table  3.3  for  the  baseline  configuration,  ALL-ON- 
SAT.  For  the  SPLIT  and  GRD  W/  ABX  configurations,  capital  costs  were  estimated  to  be 
$5000  higher  due  to  the  need  for  ground  processing  equipment  in  addition  to  the  AutoBox. 
The  GRD  W/O  ABX  option  was  also  estimated  to  be  more  expensive  due  to  the  need 
for  onboard  signal  consolidation  equipment.  This  option  also  had  higher  estimated  O&M 
costs  because  of  the  anticipated  decreased  reliability  of  a  non-integrated  solution,  relative 
to  the  integrated9  solutions.  Table  3.4  shows  the  cost  data  for  each  alternative. 


Table  3.3  Baseline  Cost  Breakdown 


Subsystem 

Capital  Costs 

O&M  Costs 

Components 

ADACS 

$17,000 

$5,000/yr 

Motors,  wheels,  sensors,  etc. 

Power 

$5,000 

$2,000/yr 

Batteries/chargers,  dist./ regulation 

C&DH/Comm 

$7,000 

$l,000/yr 

AutoBox,  wireless  LAN,  cabling 

Structures 

Materials  and  fabrication 

TOTAL 

ALL-ON-SAT  baseline 

Table  3.4  Raw  Cost  Data 


Alternative 

Capital  Costs 

O&M  Costs 

ALL- ON-SAT 

$29,500 

$8,000/yr 

SPLIT 

$8,000/yr 

GRD  W/  ABX 

$8,000/yr 

GRD  W/O  ABX 

$34,500 

$8,500/yr 

8See  Section  3.2.7  for  a  description  of  each  measurable  within  the  VSD. 

9  “Integrated”  refers  to  the  use  of  dSPACE’s  AutoBox  with  the  dSPACE  ground  station. 
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3. 3. 5. 2  Schedule.  To  determine  Total  Delivery  Weeks,  estimates  for  the 
order10,  delivery,  and  integration  times  for  each  subsystem  were  made.  Several  assumptions 
were  made  in  this  analysis.  First,  it  was  assumed  that  all  order  and  delivery  times  of 
components  would  occur  simultaneously.  Thus,  the  system-level  order  and  delivery  time 
would  be  the  maximum  of  the  subsystem  order  and  delivery  times.  Second,  the  integration 
of  the  system  was  assumed  to  begin  once  all  subsystems  were  received.  Moreover,  the 
system  integration  time  would  be  the  summation  of  the  individual  subsystem  integration 
times.  The  total  delivery  metric  represented  overall  delivery  time  of  the  system  to  the 
customer,  thus  including  both  order/delivery  and  integration  of  subsystems.  Table  3.5 
lists  the  raw  schedule  estimates  for  each  subsystem,  using  the  ALL-ON-SAT  baseline.  11 


Table  3.5  Baseline  Schedule  Breakdown 


Subsystem 

Order 

Delivery 

Integration 

ADACS 

5  weeks 

10  weeks 

6  weeks 

Power 

8  weeks 

4  weeks 

4  weeks 

C&DH/Comm 

4  weeks 

15  weeks 

3  weeks 

Structures 

2  weeks 

3  weeks 

2  weeks 

TOTAL 

Order/Delivery 

Integration 

Total  Delivery 

ALL-ON-SAT 

19  weeks 

15  weeks 

34  weeks 

For  the  SPLIT  option,  an  additional  week  was  added  to  the  C&DH  order  and  delivery 
time  to  account  for  the  impact  of  selecting  and  ordering  additional  hardware  and  software. 
Similarly,  the  GRD  W/  ABX  option  also  includes  this  additional  week,  as  well  as  an  added 
2  weeks  to  account  for  additional  software  integration.  For  the  GRD  W/O  ABX  option, 
more  research  would  be  required  to  determine  the  required  signal  consolidation  equipment 
and  select  a  preferred  vendor,  resulting  in  2  weeks  additional  order  time  relative  to  the 
baseline.  Furthermore,  the  integration  time  would  also  be  longer  to  account  for  this  non- 
integrated  solution.  Table  3.6  shows  the  raw  schedule  data  for  each  system  alternative. 


10Order  times  included  the  selection  of  the  components,  granting  of  expenditure  authority,  and  processing 
of  all  necessary  paperwork. 

11  These  estimates  were  made  in  the  summer  of  1998,  allowing  for  delivery  of  the  system  before  March 
1999. 
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Table  3.6  Raw  Schedule  Data 


Alternative 

Total  Delivery  Weeks 

Comment 

ALL- ON-SAT 

34 

Baseline 

SPLIT 

35 

Additional  processor 

GRD  W/  ABX 

37 

Software  integration 

GRD  W/O  ABX 

40 

Further  integration 

3. 3. 5. 3  Safety.  The  Relative  Damage  Index  and  Relative  Injury  Index 
were  difficult  to  accurately  quantify  at  this  point,  but  relative  estimates  were  possible. 
The  indices,  which  ranged  from  1  (extremely  dangerous  and  unacceptable)  to  20  (no  in¬ 
herent  danger),  were  estimated  using  mental  modeling  of  possible  dangers  associated  with 
the  different  alternatives.  Because  all  the  subsystems  were  to  be  commercially  available 
or  carefully  designed  products,  they  were  expected  to  meet  industry  and  military  safety 
standards.  Careful  consideration  of  safety  issues  was  stressed  throughout  the  design  pro¬ 
cess,  as  well.  Thus,  no  anticipated  substantial  safety  risks  were  identified.  To  provide 
for  unanticipated  system  interactions,  the  damage  and  injury  indices  were  conservatively 
estimated  to  be  18,  which  was  an  acceptable  value.  For  the  GRD  W/O  A  BX  opt  ion,  these 
index  estimates  were  reduced  to  16;  the  decrease  due  to  the  required  integration  of  a  non- 
validated,  piece-part  design.  Table  3.7  shows  the  raw  values  corresponding  to  the  safety 
measurables. 


Table  3.7  Raw  Safety  Data 


Alternative 

Relative  Damage  Index 

Relative  Injury  Index 

ALL-ON-SAT 

18 

18 

SPLIT 

18 

18 

GRD  W/  ABX 

18 

18 

GRD  W/O  ABX 

16 

16 

3. 3. 5. 4  Performance:  Execution.  System  evaluations  with  respect  to 
the  Execution  performance  value  are  summarized  below  for  each  evaluation  consideration 
and  its  associated  measurables.  Execution  measurables  were  discussed  in  Section  3.2. 7.4 
and  are  shown  in  the  objective  hierarchy  on  page  3-11. 
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Controllability.  Processor  Schedulability  Analysis  quantified  the 
support  for  RMA  by  the  system.  The  ALL-ON-SAT ',  SPLIT,  and  GRD  W/  ABX  alterna¬ 
tives  all  offered  “full”  RMA  support  using  the  dSPACE  system.  However,  the  GRD  W/O 
ABX  option  was  rated  as  “moderate”  support.  Although  also  using  the  dSPACE  ground 
software,  additional  hand-coded  routines  would  likely  be  required  to  support  schedulability 
analysis  using  the  onboard  non-dSPACE  hardware  in  the  GRD  W/O  ABX  configuration 
[26:B-9]. 

Communications  Latency  was  concerned  with  what  part  of  the  control  system  would 
be  impacted  by  communications  delays.  The  following  scale  was  used  to  model  this  impact 
relative  to  the  ALL-ON-SAT  baseline:  minimum,  moderate,  and  significant.  A  rating 
of  “minimum”  would  be  used  if  communication  delays  were  low,  and  had  little  impact. 
The  ALL-ON-SAT  option  was  rated  as  “minimum”  because  all  processing  would  occur 
onboard  the  satellite,  thereby  incorporating  the  least  signal  delays  between  sensors,  control 
elements,  and  effectors.  Following  this  same  reasoning,  the  SPLIT  option  was  rated  as 
“moderate”,  since  some  processing  would  be  onboard.  The  offboard  processing  options 
both  rated  “signicant”  latency  due  to  the  impacts  of  offboard  control  law  execution. 

Bandwidth  Requirement,  although  correlated  with  the  communications  latency,  was 
a  separate  measure  of  communications  data  flow  requirements.  Mental  modeling  was  used 
to  estimate  the  bandwidth  required  for  each  alternative  using  the  following  resolution:  low, 
moderate,  and  high.  The  ALL-ON-SAT  alternative  scored  “low”  because  only  command 
and  display  data  need  be  transferred  from  the  ground  to  the  satellite.  In  the  SPLIT  con¬ 
figuration,  additional  telemetry  data  and  effector  commands  would  be  required  to  execute 
offboard  ADAC  functions;  thus,  the  “moderate”  rating  for  this  option.  The  high  data  re¬ 
quirements  of  the  offboard  processing  options  led  to  a  rating  of  “high”  for  the  bandwidth 
requirement. 

Raw  values  for  the  Controllability  measures  are  summarized  in  Table  3.8. 

Data  Capability.  Initially,  the  binary  measures  of  Post-Mission 
Data  Analysis  and  Real-Time  Data  were  expected  to  provide  some  differentiation  of  system 
alternatives.  However,  each  alternative  considered  would  support  both  real-time  data 
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Table  3.8  Raw  Performance  Data:  Controllability 


Alternative 

Processor 
Sched.  Analysis 

Communications 

Latency 

Bandwidth 

Requirement 

ALL-ON-SAT 

Pull 

Minimum 

Low 

SPLIT 

Full 

Moderate 

Moderate 

GRD  W/ABX 

Full 

Significant 

High 

GRD  W/O  ABX 

Moderate 

Significant 

High 

display,  as  well  as  post-mission  data  playback  and  manipulation,  as  shown  in  Table  3.9. 
This  result  was  due  to  the  use  of  the  dSPACE  ground  software  in  all  configurations. 


Table  3.9  Raw  Performance  Data:  Data  Capability 


Alternative 

Post-Mission 
Data  Analysis 

Real-Time 

Data 

ALL-ON-SAT 

Yes 

Yes 

SPLIT 

Yes 

Yes 

GRD  W/ABX 

Yes 

Yes 

GRD  W/O  ABX 

Yes 

Yes 

Satellite  Movement.  At  this  stage  of  the  design,  a  determination 
of  specific  rate  gyros  to  be  used  for  the  attitude  determination  function  was  not  made. 
Therefore,  all  of  the  alternatives  incorporated  a  common  baseline  IMU.  As  stated  previ¬ 
ously,  synthesis  of  specific  rate  gyro  options  was  left  to  the  Detailed  Design  phase.  Slew 
Rate  Sensing ,  therefore,  did  not  offer  differentiation  of  alternatives  at  this  stage  and  need 
not  be  evaluated. 

As  with  the  slew  rate  sensing,  Rate  Sensing  Accuracy  did  not  differentiate  solutions 
at  this  stage  since  each  solution  used  a  baseline  IMU. 

Slew  Capability  was  defined  as  the  maximum  slew  angle  capable  within  a  lOsec  slew 
maneuver.  Initial  system  estimates  and  mental  modeling  were  used  to  analyze  this  mea¬ 
sure.  A  baseline  system  comprising  the  AutoBox  onboard  was  used,  with  an  estimated 
slew  capability  of  60°/10sec.  This  baseline  assumed  momentum  wheels/motors,  two  large 
batteries,  and  a  generic  payload  would  also  be  placed  onboard,  along  with  associated  com- 
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munications  and  structural  equipment.  The  ALL-ON-SAT,  SPLIT,  and  GRD  W/  ABX 
options  all  incorporated  an  onboard  AutoBox,  and  their  slew  rates  were  estimated  as 
60°/10sec.  The  GRD  W/O  ABX  alternative  did  not  incorporate  the  AutoBox  onboard, 
and  allowed  greater  flexibility  in  the  arrangement  of  components.  Thus,  this  option  could 
accommodate  lower  moment-of-inertia  properties,  and  therefore  higher  slew  rates.  An  es¬ 
timate  of  70°/10sec  was  used  for  the  GRD  W/O  ABX  slew  capability.  These  estimates, 
although  rough  approximations,  served  the  purpose  of  relative  differentiation. 

Table  3.10  summarizes  the  analysis  data  for  the  Satellite  Movement  measures. 


Table  3.10  Raw  Performance  Data:  Satellite  Movement 


Alternative 

Slew  Rate 
Sensing 

Rate  Sensing 
Accuracy 

Slew 

Capability 

ALL-ON-SAT 

(not  evaluated) 

(not  evaluated) 

60°/10sec 

SPLIT 

(not  evaluated) 

(not  evaluated) 

60°/10sec 

GRD  W/  ABX 

(not  evaluated) 

(not  evaluated) 

60°/10sec 

GRD  W/O  ABX 

(not  evaluated) 

(not  evaluated) 

70°/10sec 

3. 3. 5. 5  Performance:  Robustness.  System  evaluations  with  respect 
to  the  Robustness  performance  value  are  summarized  below  for  each  evaluation  consid¬ 
eration  and  its  associated  measurables.  Robustness  measurables  were  discussed  in  Sec¬ 
tion  3.2.7.4  and  are  shown  in  the  objective  hierarchy  on  page  3-11. 

Range  of  Experiments.  The  Interface  Modularity  metric  was 

measured  in  terms  of  the  percentage  of  components  that  must  be  relocated  or  removed  in 
order  to  accommodate  an  experiment.  The  following  list  describes  the  resolution  used  in 
the  mental  modeling  of  each  configuration: 

•  None.  Only  complete  subsystems  can  be  replaced  with  payload  parts;  no  component 
swapping  is  possible. 

•  Some.  10-50%  of  components  can  be  relocated  or  substituted  to  accommodate  an 
experimental  payload. 
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•  Partial.  50-75%  of  components  can  be  relocated  or  substituted  to  accommodate  an 
experimental  payload. 

•  Full.  All  of  the  baseline  components  can  be  relocated  or  substituted  to  accommodate 
an  experimental  payload. 

For  the  alternatives  considered,  it  was  assumed  that  use  of  the  onboard  AutoBox  would 
make  rearrangement  of  the  onboard  C&DH  subsystem  difficult  due  to  the  AutoBox’s  size 
and  integrated  hardware.  Thus,  the  ALL-ON-SAT,  SPLIT,  and  GRD  W/  ABX  configu¬ 
rations  were  all  rated  “partial”  in  terms  of  interface  modularity.  The  “piece-part”  nature 
of  the  GRD  W/O  ABX  option  would  allow  increased  flexibility  in  accommodating  experi¬ 
mental  payloads,  and  was  hence  rated  as  “full”  interface  modularity. 

Experiment  Types  measured  the  robustness  of  the  system  with  respect  to  ability  to 
support  various  experiments  desired  by  the  user.  The  resolution  used  in  the  modeling  of 
each  configuration  is  summarized  by  the  following  experimental  support  levels: 

•  None.  No  experimental  support. 

•  Educational.  Only  spinner  experimental  support. 

•  Rigid.  Spinner  and  3-axis  stabilized  (rigid  body)  experimental  support. 

•  Full.  Full  experimental  support:  spinner,  3-axis  stabilized  (rigid  and  flexible  exper¬ 
iments). 

The  AutoBox  options  were  assumed  to  handle  all  experimental  types,  based  on  the  in¬ 
tegrated  dSPACE  software  and  32  in/32  out  data  channel  capability.  However,  the  non- 
Autobox  option  ( GRD  W/O  ABX)  may  not  be  able  to  handle  all  the  data  requirements 
of  a  flexible  experiment  (e.g.,  vibration  suppression).  Thus,  this  option  received  a  “rigid” 
rating  for  this  measure. 

Table  3.11  shows  the  scores  for  each  configuration  for  the  Range  of  Experiments 
measures. 
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Table  3.11  Raw  Performance  Data:  Range  of  Experiments 


Alternative 

Interface  Modularity 

Experiment  Types 

ALL-ON-SAT 

Partial 

Full 

SPLIT 

Partial 

Full 

GRD  W/  ABX 

Partial 

Full 

GRD  W/O  ABX 

Full 

Rigid 

Available  Margins.  The  Mass  Margin  of  each  configuration  was 
modeled  through  the  summation  of  all  onboard  components.  A  baseline  mass  budget 
using  an  onboard  AutoBox  is  shown  in  Table  3.12.  These  rough  mass  estimates  were 
based  on  vendor  research,  and  engineering  approximations.  Since  the  air-bearing  supports 
approximately  150kg,  the  total  system  mass  was  subtracted  from  this  value  to  calculate 
the  mass  margin  (maximum  payload  weight).  Thus,  the  AutoBox  options  offered  100kg 
mass  margins.  The  non- AutoBox  option  was  assumed  to  use  lighter,  more  compact,  signal 
consolidation  equipment  relative  to  the  AutoBox.  Furthermore,  this  would  allow  a  tighter 
structure,  reducing  structural  weight  as  well.  Thus,  a  savings  of  20kg  was  estimated  for 
the  GRD  W/O  ABX  alternative,  resulting  in  a  120kg  mass  margin. 


Table  3.12  Baseline  Mass  Breakdown 


Subsystem 

Estimated  Mass 

Components 

ADACS 

18kg 

Motors,  wheels,  sensors,  etc. 

Power 

7kg 

Batteries/chargers,  dist. /regulation 

10kg 

AutoBox,  wireless  LAN,  cabling 

Materials  and  supports 

ALL-  ON-SA  T  baseline 

The  Power  Margin  estimates  also  required  baseline  system  approximations.  In  order 
to  account  for  experiment  duration,  it  was  decided  that  Amp-hours  (A-hr)  would  be  a 
better  unit  of  measurement  than  total  Watts.  The  ADACS  subsystem  was  estimated  to 
require  200W  of  power.  The  AutoBox  135W  specification  [19:121]  was  used  to  estimate 
C&DH  power  consumption  for  the  ALL-ON-SAT ,  SPLIT ,  and  GRD  W/  ABX  alternatives. 
An  additional  10W  was  assumed  for  wireless  communications  and  other  onboard  sensors. 
Assuming  a  nominal  bus  voltage  of  24V  and  experiment  duration  of  60  minutes,  the  total 
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345W  power  demand  resulted  in  12.32  A-hr,  which  was  rounded  to  13  A-hr  to  account  for 
line  losses.  The  power  system  baseline  was  estimated  to  be  two  10  A-hr  batteries,  thus 
providing  20  A-hr  onboard.  Thus,  the  baseline  power  margin  was  7  A-hr.  For  the  non- 
AutoBox  solution,  the  signal  consolidation  equipment  was  assumed  to  use  much  less  power 
than  the  AutoBox  assembly,  which  was  designed  for  much  more  than  just  signal  processing. 
An  estimate  of  50W  was  used  for  the  GRD  W/O  ABX  C&DH  power  consumption,  resulting 
in  a  10  A-hr  power  margin. 

Table  3.13  shows  the  mass  and  power  margins  for  each  configuration. 


Table  3.13  Raw  Performance  Data:  Available  Margins 


Alternative 

Mass  Margin  (kg) 

Power  margin  (A-hr) 

ALL-ON-SAT 

100 

7 

SPLIT 

100 

7 

GRD  W/  ABX 

7 

GRD  W/O  ABX 

10 

3.3.5. 6  Performance:  Ease  of  Use.  System  evaluations  with  respect 
to  the  Ease  of  Use  performance  value  are  summarized  below  for  each  evaluation  consider¬ 
ation  and  its  associated  measurables.  These  measurables  were  discussed  in  Section  3.2.7.4 
and  are  shown  in  the  objective  hierarchy  on  page  3-11. 

Ground  Station  Capability.  The  Control  System  Analysis  metric 
was  defined  as  the  percentage  of  system  components  readily  defined  by  the  ground  station, 
in  terms  of  geometric,  mass,  and  inertial  properties.  The  following  resolution  was  used 
in  this  modeling:  minimal  (<  50%  readily  defined),  partial  (50  —  90%  readily  defined), 
and  full  (>  90%  readily  defined).  The  onboard  AutoBox  options  were  determined  to  have 
“full”  capability,  since  the  AutoBox  could  easily  be  modeled  along  with  the  other  onboard 
systems.  The  GRD  W/O  ABX  alternative  made  this  analysis  more  difficult,  due  to  the 
non-integrated  onboard  hardware.  Because  this  solution  was  “piece-part”  in  nature,  it 
was  not  as  well  defined  ahead-of-time,  relative  to  the  AutoBox.  Thus,  this  alternative  was 
rated  “partial”  capability. 
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The  Development  Environment  measure  referred  to  the  type  of  development  interface: 
text,  graphical,  or  object-oriented.  The  dSPACE  ground  station  used  a  Simulink  interface 
which  can  represent  all  input  and  output  signals  of  the  AutoBox.  Thus,  all  AutoBox-based 
solutions  were  modeled  as  object-oriented  development  environments.  The  signal  consol¬ 
idation  of  a  non-AutoBox  solution  would  not  be  as  easily  handled  within  the  dSPACE- 
Simulink  model,  and  thus  the  GRD  W/O  ABX  option  was  considered  a  graphical-only 
development  environment. 

Although  the  dSPACE  simulation  of  the  satellite  motion  may  be  more  complex  with¬ 
out  the  use  of  the  AutoBox,  all  system  alternatives  would  be  capable  of  modeling  satellite 
behavior  prior  to  execution  of  an  experiment.  Thus,  the  Motion  Simulation  capability 
would  exist  for  each  option. 

Table  3.14  consolidates  the  raw  data  for  the  Ground  Station  Capability  measurables. 


Table  3.14  Raw  Performance  Data:  Ground  Station  Capability 


Alternative 

Control  System 
Analysis 

Development 

Environment 

Motion 

Simulation 

ALL-ON-SAT 

Full 

Object-Oriented 

Yes 

SPLIT 

Full 

Object-Oriented 

Yes 

GRD  W/ ABX 

Full 

Object-Oriented 

Yes 

GRD  W/O  ABX 

Partial 

Graphical 

Yes 

Command  and  Control.  The  percentage  of  displays/controls  pre¬ 
sented  graphically  to  the  user  was  defined  as  the  User  Interface  measure.  Similar  to  Control 
System  Analysis ,  the  following  resolution  was  used  in  the  mental  modeling  of  this  measure: 
minimal  (<  50%  graphically  displayed),  partial  (50  —  90%  graphically  displayed),  and  full 
(>  90%  graphically  displayed).  Because  the  dSPACE  environment  allows  easy  graphical 
manipulation,  all  AutoBox-based  solutions  were  rated  “full”  user  interface  capability.  The 
GRD  W/O  ABX  option  may  not  incorporate  as  easy  an  interface  due  to  non-dSPACE 
signal  consolidation.  If  full  capability  could  be  achieved,  it  was  expected  to  require  much 
more  development.  Thus,  this  option  was  rated  “partial”  capability  at  this  stage. 
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Command  Capability  used  the  following  scale,  increasing  in  command  capability: 
only  experiment  start/stop  commands,  AD  ACS  control,  and  ADACS/payload  control.  All 
alternatives  provided  for  full  ADACS/payload  control.  The  relative  ease  of  this  control 
was  reflected  in  other  measurables. 

Table  3.15  shows  the  Command  and  Control  measurables  data. 


Table  3.15  Raw  Performance  Data:  Command  and  Control 


Alternative 

User  Interface 

Command  Capability 

ALL- ON-SAT 

Pull 

Pull 

SPLIT 

Pull 

Pull 

GRD  W/  ABX 

Pull 

Full 

GRD  W/O  ABX 

Partial 

Pull 

O&M  Time.  Maintenance  and  Test  Time  measured  the  time  re¬ 
quired  to  install  a  payload  and  validate  the  system  for  operation.  As  defined  in  Appendix  A, 
this  measure  ranged  from  “very  low”  (under  15  minutes)  to  “very  high”  (more  than  100 
minutes).  The  AutoBox  solutions  allowed  simple  signal  interfaces  to  the  AutoBox,  and 
would  require  less  validation  due  to  the  integrated  dSPACE  hardware.  Thus,  a  “very  low” 
time  was  warranted  for  these  alternatives.  Because  the  GRD  W/O  ABX  option  made 
signal  interfacing  less  straightforward,  it  was  anticipated  that  configuring  an  experiment 
would  require  more  time,  and  a  rating  of  “low”  (16-35  minutes)  was  given. 

Turn-Around  Time  considered  only  the  time  required  to  reset  the  configuration  for 
a  like  experiment.  Since  this  time  was  most  impacted  by  power  (battery  change-outs) 
and  structures  (accessibility)  issues,  the  alternatives  at  this  stage  did  not  provide  any 
differentiation.  Thus,  this  measure  need  not  be  evaluated  since  it  only  considered  baseline 
subsystems  that  were  as  yet  not  fully  defined. 

Table  3.16  shows  the  O&M  Time  measurable  data. 

3.3.6  Utility  Scale.  A  utility  scale,  ranging  from  0  (no  utility)  to  10 
(highest  utility),  was  used  to  scale  each  raw  value.  This  common  scale  thereby  allowed  all 
the  measurable  data  to  be  directly  compared.  The  design  team  explicitly  solicited  utility 
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Table  3.16  Raw  Performance  Data:  O&M  Time 


Alternative 

Maintenance  &  Test  Time 

Turn-Around  Time 

ALL-ON-SAT 

Very  Low 

(not  evaluated) 

SPLIT 

Very  Low 

(not  evaluated) 

GRD  W/  ABX 

Very  Low 

(not  evaluated) 

GRD  W/O  ABX 

Low 

(not  evaluated) 

(preference)  data  from  the  decision  makers/customers;  this  data  was  used  to  create  utility 
curves  for  each  measure,  as  shown  in  Appendix  A.  Table  3.17  is  a  tabular  representation 
of  these  utility  curves  for  each  measure.  The  exact  utility  curves  in  Appendix  A  were  used 
in  actual  scaled  score  calculations.  These  scaled  scores  are  shown  in  Table  3.18  for  each  of 
the  four  system  alternatives. 


3.4  Interpretation 

3.4 -I  Dominated  Solutions.  As  Table  3.18  shows,  the  SPLIT  sand  GRD 
W/  ABX  were  dominated  solutions.  This  term  implies  that  another  alternative  was  greater 
or  equal  in  value  for  every  measurable  related  to  these  options.  Specifically,  both  the 
ALL-ON-SAT  and  SPLIT  alternatives  dominated  the  GRD  W/  ABX  alternative,  and 
the  ALL-ON-SAT  alternative  dominated  the  SPLIT  alternative  as  well.  This  conclusion 
was  logical  since  these  two  solutions  were  based  on  some  offboard  processing  with  an 
onboard  AutoBox,  thereby  including  the  negative  system  impacts  of  offboard  processing 
delays  along  with  the  negative  system  impacts  of  the  large  AutoBox  assembly.  Thus,  the 
SPLIT  and  GRD  W/  ABX  options  were  not  considered  further  in  the  decision-making 
process12.  The  GRD  W/O  ABX  option,  however,  was  not  dominated,  since  removal  of  the 
AutoBox  gained  certain  advantages  in  terms  of  modularity,  slew  capability,  and  available 
mass  and  power  margins.  Thus,  additional  decision-making  analysis  was  needed  to  resolve 
the  preference  of  the  ALL-ON-SAT  versus  GRD  W/O  ABX  alternatives. 

12  The  thesis  of  Mr.  Hanke  [26]  included  all  four  options  for  follow-on  consideration.  The  decision-making 
techniques  of  this  phase  were  similar,  but  not  identical,  to  those  employed  by  Mr.  Hanke  in  his  C&DH 
evaluations.  The  scaled  scores,  weighting  factors,  and  resulting  system  scores  were  not  identical. 
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Table  3.17  Common  Utility  Scale 


Utility  Scale 

No  utility 

Little  utility 

Fair  utility 

Good  utility 

Excellent  utility 

Objective  Measurable 

0 

2 

5 

7 

10 

Capital  costs 

$100,000 

$86,000 

$65,000 

$50,000 

$10,000 

O&M  costs  (per  year) 

$10,000 

$8,750 

$6,875 

$5,000 

$0 

Total  delivery  weeks 

56 

53 

48 

43 

24 

Relative  damage  index 

10 

12 

15 

17 

20 

Relative  injury  index 

10 

12 

15 

17 

20 

Processor  sched.  analysis 

None 

Unsupported 

Moderate 

Full 

Communications  latency 

Significant 

Moderate 

Minimal 

Bandwidth  requirement 

High 

Moderate 

Low 

Post-mission  data  analysis 

No 

Yes 

Real-time  data 

No 

Yes 

Slew  rate  sensing 

(not  evaluated) 

Rate  sensing  accuracy 

(not  evaluated) 

Slew  capability  (deg/lOsec) 

30 

38 

50 

60 

100 

Interface  modularity 

None 

Some 

Partial 

Full 

Experiment  types 

None 

Educational 

Rigid 

Full 

Mass  margin  (kg) 

0 

25 

55 

80 

300 

Power  margin  (A-hr) 

0 

1 

2 

4 

15 

Control  system  analysis 

Minimal 

Partial 

Full 

Development  environment 

Text 

Graphical 

Object-Oriented 

Motion  simulation 

No 

Yes 

User  interface 

Minimal 

Partial 

Full 

Command  capability 

Start/Stop-only 

ADACS-only 

ADACS/Payload 

Maintenance  &  test  time 

Very  High 

High 

Moderate 

Low 

Very  Low 

Turn-around  time 

(not  evaluated) 
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Table  3.18  Scaled  Scores  Summary 


Objective  Measurable 

Scaled  Scores  (Common  Units,  0  to  10) 

ALL-ON-SAT 

SPLIT 

GRD  W/ABX 

GRD  W/O  ABX 

Capital  costs 

8.7 

8.4 

8.4 

8.4 

O&M  costs 

3.5 

3.5 

3.5 

2.7 

Total  delivery  weeks 

8.9 

8.7 

8.4 

7.7 

Relative  damage  index 

8 

8 

8 

6 

Relative  injury  index 

8 

8 

8 

6 

Processor  sched.  analysis 

10 

10 

10 

7 

Communications  latency 

10 

5 

0 

0 

Bandwidth  requirement 

10 

5 

0 

0 

Post-mission  data  analysis 

10 

10 

10 

10 

Real-time  data 

10 

_ 10 

10 

10 

Slew  rate  sensing 

(not  evaluated) 

Rate  sensing  accuracy 

(not  evaluated) 

Slew  capability 

7.0 

7.0 

7.0 

8.2 

Interface  modularity 

6 

6 

6 

10 

Experiment  types 

10 

10 

10 

7 

Mass  margin 

8.0 

8.0 

8.0 

8.6 

Power  margin 

9.1 

9.1 

9.1 

9.7 

Control  system  analysis 

10 

10 

10 

7 

Development  environment 

10 

10 

10 

7 

Motion  simulation 

10 

10 

10 

10 

User  interface 

10 

10 

10 

7 

Command  capability 

10 

10 

10 

10 

Maintenance  &  test  time 

10 

10 

10 

7 

Turn-around  time 

(not  evaluated) 
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3.^.2  Worth  Assessment  Methodology .  System  ranking  and  selection 
were  based  on  an  overall  worth  assessment.  This  decision-making  procedure  was  used  to 
translate  scaled  utility  scores  for  each  measure  into  system  scores  for  the  remaining  two 
alternatives.  Sage  described  a  six-step  process  in  the  overall  assessment  of  system  worth, 
as  summarized  below  [49:356-358]: 

•  List  the  overall  performance  objectives  or  attributes. 

•  Construct  a  hierarchy  of  performance  criteria. 

•  Select  appropriate  physical  performance  measures. 

•  Define  the  relationship  between  low-level  criteria  and  physical  performance  measures; 
i.e.,  deal  with  the  scoring  problem. 

•  Establish  relative  importance  within  the  subcriteria  set. 

•  Adjust  the  weights  to  reflect  confidence  in  the  performance  measures. 

The  first  three  steps  in  Sage’s  method  were  accomplished  in  the  value  system  design,  in 
which  overall  values  were  defined,  and  associated  measurables  were  developed  and  arranged 
in  the  objective  hierarchy.  The  fourth  step  corresponded  to  the  development  of  a  common 
utility  scale,  from  which  scaled  scores  were  calculated.  The  fifth  and  sixth  steps  represented 
the  development  of  weighting  factors  for  each  objective  measure.  This  determination  of 
weighting  factors  is  summarized  in  Section  3.4.3. 

5.^.5  Weighting  Factors .  Weighting  factors  were  developed  for  each  mea¬ 
sure  of  the  objective  hierarchy  through  interactive  discussion  with  the  decision  makers. 
These  factors  were  assigned  such  that  the  multipliers  for  each  level  of  the  objective  hier¬ 
archy  summed  to  1,  as  shown  in  Figure  3.8.  The  multipliers  for  each  top  level  were  then 
multiplied  by  the  sublevel  multipliers,  all  the  way  down  to  the  objective  measurables,  to 
calculate  a  single  weighting  factor  for  each  measurable.  In  this  way,  a  weighting  factors 
vector  was  created  (with  sum  of  components  equal  to  1),  which  was  multiplied  by  the 
matrix  of  scaled  scores  (Figure  3.18)  to  determine  a  system  score  for  each  alternative. 
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Figure  3.8  Preliminary  Design  Weighted  Hierarchy 
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3. 4- 3.1  Adjustments.  Because  the  Data  Capability  evaluation  consider¬ 
ation  revealed  no  system  differentiation  (all  of  the  alternatives  incorporated  post-mission 
and  real-time  data  analysis),  the  weighting  factor  for  this  branch  was  redistributed  to  the 
Controllability  and  Satellite  Movement  branches.  Thus,  their  corresponding  weights  were 
increased  from  0.4  to  0.5  to  better  provide  system  differentiation  for  the  decision  mak¬ 
ers.  Similarly,  the  weight  corresponding  to  the  Turn-Around  Time  was  redistributed  to 
the  Ground  Station  Capability  and  Command  and  Control  branches.  The  weight  was  not 
lumped  with  the  Maintenance  and  Test  Time  because  this  action  would  have  significantly 
increased  the  importance  of  this  measure,  whereas  redistribution  to  the  other  branches 
was  considered  to  aid  in  the  system  differentiation  without  inflating  the  importance  of  any 
specific  measure.  Thus,  the  Ground  Station  Capability  branch  was  increased  from  0.4  to 
0.5,  and  the  Command  and  Control  was  increased  from  0.2  to  0.3. 

Although  Slew  Rate  Sensing  and  Rate  Sensing  Accuracy  were  not  applicable  to  the 
solutions  analyzed  in  this  phase13,  the  weights  of  these  measures  were  not  redistributed, 
thus  avoiding  over-inflation  of  the  Slew  Capability  measure.  Instead,  the  two  alternatives 
were  considered  of  equal  utility  (an  arbitrary  value  of  7)  for  these  respective  measures. 

3. 4.3. 2  Confidence  Factors.  As  stated  previously,  the  level  of  confi¬ 
dence  associated  with  the  measurable  data  was  considered  equal  at  this  stage  of  the  design. 
Thus,  no  adjustments  were  made  based  on  confidence  factors. 

3. 4- 3.3  Weighting  Factors  Vector.  Weights  for  each  measure  were  de¬ 
termined  by  multiplying  the  weighting  factors  from  the  bottom  of  the  hierarchy  (objective 
measures)  to  the  top  (top-level  values).  These  weights  provided  a  means  of  ranking  the 
objective  measures  to  ensure  that  important  measures  were  weighted  more  heavily.  The 
decision  maker  was  able  to  adjust  the  branch  and  measure  weights  that  resulted  in  the 
finalized  weighting  vector.  This  resulting  weighting  factors  vector  is  shown  in  Table  3.19. 

13The  measurable  weighting  factors  were  developed  before  preliminary  system  analysis  revealed  the  sys¬ 
tem  configurations  which  would  require  detailed  measurable  data  for  comparison. 
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Table  3.19  Weighting  Factors  Vector 


Measurable 

Weighting  Factor 

Capital  Cost 

0.160 

O&M  Cost 

Total  Delivery  Weeks 

Relative  Damage  Index 

Relative  Injury  Index 

hh 

Processor  Schedulability  Analysis 

Communications  Latency 

Bandwidth  Requirement 

■■ElllHHi 

Post-Mission  Data  Analysis 

0.000 

Real-Time  Data 

0.000 

Slew  Rate  Sensing 

Rate  Sensing  Accuracy 

Slew  Capability 

Interface  Modularity 

Experiment  Types 

Mass  Margin 

0.045 

Power  Margin 

0.045 

Control  System  Analysis 

Development  Environment 

Motion  Simulation 

0.025 

User  Interface 

■■musH 

Command  Capability 

Maintenance  &  Test  Time 

Turn-Around  Time 

Components  Sum 

1.000 

3.4-4  System  Scoring.  Since  the  system  scores  were  determined  by  mul¬ 
tiplying  the  scaled  scores  matrix  by  the  weighting  factors  vector,  the  scoring  range  also 
varied  from  0  (no  utility)  to  10  (excellent  utility).  The  system  scores  for  the  ALL-ON-SAT 
and  GRD  W/O  ABX  alternatives  are  shown  in  Table  3.20.  The  ALL- ON-S AT  alternative 
scored  higher  than  the  GRD  W/O  ABX  alternative  for  each  top-level  value. 


3.4-5  Sensitivity  Analysis.  Before  selecting  the  ALL-ON-SAT  alternative 
based  on  system  scores,  the  ranking  of  alternatives  was  investigated  to  determine  sensitivity 
to  the  weighting  factors.  This  sensitivity  analysis  allowed  understanding  of  how  the  system 
scores  were  dependent  on  the  weighting  factors  used  in  the  decision-making  process. 
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Table  3.20  System  Scoring  Results 


System  Scoring  by  Value 


■  Performance 

4.47 

3.53 

□  Safety 

0.80 

0.60 

U  Schedule 

1.78 

1.54 

□  Cost 

1.53 

1.45 

3. 4- 5.1  Cost,  Schedule,  and  Safety.  Because  the  ALL-ON-SAT  alter¬ 
native  was  rated  superior  to  the  GRD  W/O  ABX  alternative  in  every  cost,  schedule,  and 
safety  measure,  no  alteration  of  lower-level  weighting  factors  would  allow  the  GRD  W/O 
ABX  option  to  show  an  advantage  over  the  ALL-ON-SAT  option  for  these  values. 

3. 4- 5. 2  Performance.  In  the  Performance  hierarchy,  the  ALL-ON-SAT 
option  was  superior  or  equal  in  all  Ease  of  Use  measures.  Moreover,  the  ALL-ON-SAT 
option  was  superior  or  equal  in  all  Execution  measures,  except  Slew  Rate  Sensing.  Because 
of  the  dominance  of  the  ALL-ON-SAT  in  most  measures  within  the  Execution  branch, 
only  extremely  skewed  weighting  of  the  Slew  Rate  Sensing  measure  could  possibly  result 
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in  the  GRD  W/0  ABX  option  having  greater  Execution  utility.  Thus,  the  ALL-ON- 
SAT  alternative  was  considered  superior  in  both  Ease  of  Use  and  Execution  under  any 
reasonable  weighting  scheme. 

For  the  Robustness  measures,  however,  the  GRD  W/O  ABX  option  showed  superior¬ 
ity  in  Mass  Margin ,  Power  Margin ,  and  Interface  Modularity ,  whereas  the  ALL-ON-SAT 
option  was  only  superior  in  terms  of  Experiment  Types.  Thus,  only  by  placing  additional 
weight  to  the  Robustness  branch  could  the  GRD  W/0  ABX  option  show  an  advantage 
over  the  ALL- ON-SAT  option. 

3. 4- 5. 3  Worst- Case  Weighting.  Assuming  the  branch  weights  of  cost, 
schedule,  and  safety  were  reduced  to  0,  the  ALL-ON-SAT  advantage  due  to  these  cate¬ 
gories  was  thereby  eliminated.  Thus,  only  the  performance  measures  were  considered  in 
the  remaining  worst-case  sensitivity  analysis.  The  challenge  was  then  to  determine  the 
weighting  scheme  amongst  the  performance  measures  which  would  show  the  GRD  W/O 
ABX  option  to  be  superior.  If  this  weighting  scheme  was  considered  unreasonable,  then 
the  ALL-ON-SAT  option  would  be  superior  under  any  reasonable  weights  breakdown. 

To  further  simplify  the  vast  solution  space  of  weighting  schemes,  the  relative  weight¬ 
ing  within  Execution  and  Ease  of  Use  were  held  constant.  This  assumption  was  reasonable 
in  this  situation  because  the  ALL-ON-SAT  option  dominated  all  but  one  measure  within 
these  categories;  varying  the  internal  weights  of  these  measures  would  not  significantly 
change  this  ALL- ON- SAT  scoring  advantage.  An  additional  assumption  was  that  the  In¬ 
terface  Modularity  measure  would  receive  all  the  weight  within  the  Range  of  Experiments 
branch  ( Experiment  Types  equal  to  0),  thus  giving  advantage  to  the  GRD  W/O  ABX 
option.  With  this  weighting  scheme,  the  relative  weights  of  the  Execution,  Robustness , 
and  Ease  of  Use  performance  considerations  could  be  traded  to  determine  favorable  GRD 
W/O  ABX  situations.  Multiplying  the  low-level  weighting  factors  against  the  utility  values 
corresponding  to  those  measures,  the  results  of  Table  3.21  were  obtained. 
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Table  3.21  Utility  of  Each  Performance  Consideration 


Evaluation  Consideration 

ALL- ON-SAT  Utility 

GRD  W/O  ABX  Utility 

Execution 

8.50 

5.14 

Robustness 

7.53 

9.49 

Ease  of  Use 

8.00 

6.30 

3. 4-5. 4  Varying  the  Performance  Weights.  Using  the  utility  values 
for  each  branch,  the  following  equations  represent  the  sensitivity  analysis  solution  space 
(where  x,  y,  and  z  are  the  Execution,  Robustness,  and  Ease  of  Use  weights,  respectively): 

8.50  •  x  +  7.53  •  y  +  8.00  -  2  =  ALL-ON-SAT  Score 
5.14  •  x  +  9.49  •  y  +  6.30  •  z  =  GRD  W/O  ABX  Score 
x+y+z = 1 
x,y,z>  0 
x,y,z  <  1 

By  setting  the  ALL-ON-SAT  and  GRD  W/O  ABX  scores  equal  to  determine  the  point 
where  the  GRD  W/O  ABX  option  becomes  favorable  under  these  worst-case  weighting 
conditions,  the  weighting  factors  solution  space  is  determined  by  two  equations  in  three 
unknowns  (the  intersection  of  two  planes  being  a  line).  Thus,  only  one  weighting  factor 
is  an  independent  variable.  For  this  analysis,  the  Robustness  weight  was  varied,  thereby 
determining  the  corresponding  weights  of  the  other  two  branches.  These  solutions  are 
shown  in  Figure  3.9. 

The  GRD  W/O  ABX  option  was  superior  in  terms  of  performance  only  when  either 
the  Execution  or  the  Ease  of  Use  considerations  were  weighted  less  than  0.22.  It  would 
require  a  considerable  shift  in  the  weighting  of  the  performance  branches,  even  in  this 
worst-case  scheme  (discounting  the  ALL-ON-SAT  advantages  in  terms  of  cost,  schedule, 
and  safety),  to  result  in  a  favorable  GRD  W/O  ABX  scenario.  For  any  weight  distribution 
considered  reasonable  (i.e.,  not  so  skewed  towards  Robustness )  by  the  team  and  decision 
maker,  the  ALL-ON-SAT  alternative  maintained  its  advantage  in  overall  utility.  Thus, 
this  advantage  was  not  very  sensitive  to  the  weighting  factors. 
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Figure  3.9  Feasible  Alternate-Result  Weighting  Factors 

3. 4-6  Preferred  Design.  Based  on  the  system  scoring  results  and  the 
sensitivity  analysis,  the  ALL-ON-SAT  option  was  selected  as  the  preferred  architecture  for 
further  design.  The  design  resulting  from  the  Preliminary  Design  phase  included  momen¬ 
tum  wheels  and  rate  gyros  for  the  ADACS  functions,  full  onboard  processing  capability 
for  the  CfeDH  system,  lead  acid  batteries  for  power,  and  COTS  wireless  communications. 
This  system  architecture  provided  a  baseline  for  more  detailed  development  in  the  Detailed 
Design  phase. 
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IV.  Detailed  Design 


4-1  Overview 

In  this  lifecycle  phase,  subsystem  design  began  in  detail.  The  subsystem  architecture 
selected  in  the  Preliminary  Design  phase  was  further  refined,  with  emphasis  on  resolving 
system  integration  and  interface  issues.  The  phase  began  with  a  system-level  investiga¬ 
tion  to  determine  the  preferred  battery  configuration,  momentum  wheel  sizes,  momentum 
wheel  motors,  and  rate  gyros.  Once  these  decisions  were  made,  detailed  subsystem  design 
began  in  full.  Research  and  system  trade  studies  were  used  to  select  preferred  subsystem 
configurations  and  vendors.  The  software  control  laws  were  developed  and  integrated  into 
the  C&DH  architecture.  Structural  design  and  subsystem  integration  were  accomplished 
using  the  systems  approach.  The  final  product  of  this  phase  was  a  detailed  functional 
system  architecture  with  subsystems  designed  and  integrated  to  the  maximum  extent  pos¬ 
sible.  This  chapter  documents  the  design  iterations  encountered  in  Detailed  Design.  The 
waterfall  design  model  in  Figure  4.1  highlights  the  focus  of  this  chapter. 


Figure  4.1  Detailed  Design  Activity 
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4‘2  First- Iteration  Issue  Formulation 


4 ‘2.1  Problem  Statement.  This  “first  cut”  through  the  Detailed  Design 
phase  addressed  the  following  problem: 

Based  on  the  subsystem  classes  developed  in  the  Preliminary  Design  phase ,  refine 
these  subsystem  alternatives  such  that  control  laws  can  be  developed ,  simulation  of  SIMS  AT 
behavior  can  be  made ,  and  structural  design  can  be  initiated  in  detail. 

4*2.2  Updated  System  Architecture.  As  a  starting  point  for  the  Detailed 
Design  phase,  the  system  architecture  resulting  from  the  Preliminary  Design  phase  was 
summarized.  The  basic  architecture  is  listed  in  Table  4.1. 


Table  4.1  Detailed  Design  Baseline  Architecture 


Subsystem 

Preliminary  Design  Decision 

Attitude  Determination 

Rate  Gyros 

Attitude  Control 

Momentum  Wheels 

Power 

Sealed  Lead  Acid  Batteries 

C&DH 

All-Onboard  AutoBox  Processing 

Communications 

COTS  Wireless  LAN/Modem 

Structures 

As  Required 

4*2.3  First- Iteration  Design  Issues. 

4*2.3. 1  AD  ACS.  The  momentum  wheel  alternative,  chosen  in  Prelimi¬ 
nary  Design,  required  the  design  of  momentum  wheels  and  the  selection  of  motors  to  drive 
the  wheels,  to  provide  attitude  control.  Attitude  determination  was  to  be  accomplished 
through  the  use  of  rate  gyros.  The  following  paragraphs  highlight  the  ADACS  issues  to  be 
addressed  in  this  design  iteration. 

Momentum  Wheels .  Three  momentum  wheels  were  used  to  pro¬ 

vide  attitude  control  torques  in  the  three  axes  -  roll,  pitch,  and  yaw.  Determination  of 
the  size  and  inertial  properties  of  the  momentum  wheels  was  required  in  order  to  begin 
wheel  fabrication,  as  well  as  to  be  used  in  system  modeling,  controller  development,  and 
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structural  design.  Thus,  the  physical  design  of  the  momentum  wheels  was  identified  as 
a  key  design  issue  to  be  addressed  in  this  first  iteration  of  Detailed  Design.  In  order  to 
evaluate  momentum  wheel  designs,  an  equations-of-motion  (EOM)  model  first  needed  to 
be  developed. 


Motors.  The  type  of  motors  used  to  rotate  the  momentum  wheels 
needed  to  be  understood  at  this  stage  to  ensure  compatibility  with  the  dSPACE  software, 
and  to  accommodate  system  modeling  and  momentum  wheel  sizing.  Motor  sizing  was 
also  necessary  for  structural  development.  Identification  of  motor  types  and  selection  of  a 
preferred  motor  class  were  therefore  identified  as  necessary  in  this  iteration. 

Rate  Gyros.  Regarding  attitude  determination,  selection  of  a  pre¬ 
ferred  rate  gyro  alternative  was  also  identified  as  a  critical  system  decision.  The  rate  gyro 
determined  much  of  the  rate  accuracy  necessary  for  controller  feedback  in  the  execution  of 
experiments.  Furthermore,  system-level  development  at  this  stage  required  narrowing  the 
rate  gyro  solution  class,  which  was  far  too  broad  for  detailed  design  of  C&DH  interfaces 
and  control  laws. 


Safety.  Because  of  the  high  RPM  momentum  wheel  design,  a  safety 
mechanism  was  required  to  prevent  small,  loose  items  onboard  the  satellite  from  ricocheting 
dangerously  off  the  wheel.  Catastrophic  failure  of  a  motor  shaft  needed  to  be  contained, 
as  well,  to  prevent  extensive  satellite  damage  and  risk  of  injury.  Thus,  an  enclosed  box 
around  the  momentum  wheels  was  also  required  as  part  of  the  momentum  wheel  assembly. 

Thrusters.  Regarding  thruster  augmentation,  selection  and  incor¬ 
poration  of  a  thruster  assembly  was  not  made  at  this  stage  of  the  design.  Thrusters  were 
identified  as  non-critical  items  for  baseline  SIMS  AT  operation  and  were  left  for  later  de¬ 
sign,  after  critical  subsystems  were  addressed.  Thrusters  were,  however,  considered  in 
the  power  requirements  and  mass/inertia  estimates  to  ensure  feasible  implementation  if 
thrusters  were  later  added. 
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4- 2. 3. 2  Power.  The  Preliminary  Design  decision  to  use  sealed  lead  acid 
batteries  did  not  specify  the  number  or  sizes  of  batteries  to  be  considered.  At  this  stage 
of  the  design,  power  requirements  needed  to  be  developed  for  each  subsystem,  battery 
configurations  needed  to  be  considered,  and  a  preferred  power  architecture  was  required. 
The  relatively  heavy  nature  of  the  power  system  made  choice  of  batteries  crucial  to  ac¬ 
commodate  structural  development,  and  to  necessitate  the  feasibility  of  subsystem  power 
requirements  before  further  design  progression  was  made. 

4 .2. 3. 3  C&DH.  The  use  of  onboard  processing  through  the  dSPACE 
AutoBox  was  resolved  in  the  Preliminary  Design  phase.  At  this  stage,  the  AutoBox  was 
ordered  and  delivered,  and  wired  integration  with  the  dSPACE  ground  software  was  ac¬ 
complished  by  Mr.  Hanke  as  part  of  his  thesis.  For  the  problem  statement  addressed  in 
this  iteration,  no  additional  C&DH  issues  were  identified  as  critical  to  continued  design. 

4-2. 3. 4  Communications.  Research  into  commercially-available  wire¬ 
less  LANs  suitable  for  AutoBox/dSPACE  connectivity  indicated  that  the  power  require¬ 
ments,  mass  properties,  and  associated  costs  of  available  systems  were  similar  1 .  At  the 
system  level,  the  wireless  LAN  choice  did  not  impact  structural  design,  control  law  devel¬ 
opment,  or  power  requirements.  Therefore,  selection  of  a  preferred  wireless  LAN  was  left 
for  a  separate  design  subproblem. 

Since  integration  of  the  RealMotion  software  was  not  addressed  at  this  stage  of  the 
design,  selection  of  a  wireless  modem  to  provide  the  RealMotion  data  link  was  also  not 
addressed.  Although  desired,  RealMotion  data  was  not  critical  to  SIMSAT  operation 
and  experimental  capability.  With  limited  schedule  available,  integration  of  the  wireless 
LAN  (a  critical  link  in  system  operation)  proceeded  the  wireless  modem  development.  As 
with  the  thruster  augmentation,  consideration  of  future  wireless  modem  integration  was 
made  at  this  stage  to  ensure  feasible  implementation  once  the  RealMotion  issues  were 
fully  addressed. 

'Section  4.2.6. 6  describes  these  systems  more  fully. 
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4-2.3. 5  Structures.  From  a  structures  standpoint,  only  a  baseline  con¬ 
cept  was  necessary  at  this  stage  of  the  design.  Structural  weight  and  inertia  properties 
could  thereby  be  used  in  system  modeling  and  momentum  wheel  development.  Detailed 
structural  development  was  left  for  after  this  first  iteration,  following  determination  of  sizes 
and  shapes  of  the  momentum  wheels,  motors,  and  batteries. 

4‘2.3.6  Issues  Summary.  The  following  list  represents  the  key  issues 
identified  for  address  in  this  design  iteration: 

•  Development  of  an  EOM  system  model. 

•  Specification  of  a  preferred  momentum  wheel  design. 

•  Selection  of  a  class  of  momentum  wheel  motors. 

•  Specification  of  rate  gyros  for  attitude  determination. 

•  Preliminary  design  of  a  momentum  wheel  casing. 

•  Determination  of  system  power  requirements. 

•  Selection  of  a  preferred  battery  configuration. 

4.2.4  Value  System  Design.  The  objectives  hierarchy  created  in  the 
Preliminary  Design  phase,  shown  in  Figure  3.5,  served  as  a  starting  point  for  a  modified 
VSD  for  this  design  iteration.  Values  and  measures  which  were  determined  to  provide  no 
system  differentiation,  with  respect  to  the  reduced  subsystem  solution  spaces,  were  elimi¬ 
nated  from  the  hierarchy.  Furthermore,  several  measures  were  added  in  order  to  capture 
some  of  the  system  aspects  compared  in  this  iteration.  The  resulting  objectives  hierarchy  is 
shown  in  Figure  4.2.  This  hierarchy  was  relatively  streamlined  and  allowed  direct  compar¬ 
ison  and  weighting  of  all  measurables  without  the  need  for  branch  weights.  The  top-level 
values  were  more  specific  than  those  addressed  in  Preliminary  Design,  corresponding  to 
the  increased  specificity  of  the  system  architecture  at  this  stage.  Modifications  from  the 
Preliminary  Design  VSD,  as  well  as  description  of  the  measurables  for  each  top-level  value, 
are  described  in  the  following  paragraphs. 
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Best  Design 


Cost  Slew/Position  Integration  Experiment 

Performance  Ease  Robustness 

—  Capital  cost 
($) 

—  Slew  rate  sensing 
(deg/s) 

—  Rate  accuracy 
(lo  w/med/high ) 

—  S lew  capability 
(deg/s  avg  for  10s) 

—  Comparative  volume 
(cubic  in) 

—  CDH  compatibility/interface 
(low/med/high) 

—  M  ass  margin 

(kg  under  maximum) 

—  Power  margin 
(available  W  atts) 

—  36V  baseline  bus  availability 
(yes/no) 

Figure  4.2  Detailed  Design  Objectives  Hierarchy 

4- 2.4-1  VSD  Modifications.  The  Schedule  value  identified  in  the  Pre¬ 
liminary  Design  VSD  was  no  longer  appropriate  at  this  stage  because  each  subsystem  class 
was  reduced  such  that  no  significant  differences  in  order,  delivery,  or  integration  times  were 
identified.  Thus,  this  value  provided  no  tradable  measures.  Similarly,  the  Safety  branch 
of  the  earlier  VSD  provided  no  identifiable  system  differentiation  at  this  stage,  and  was 
likewise  removed  as  a  top-level  value.  Cost  remained  in  the  objective  hierarchy. 

The  Performance  value  was  also  modified  significantly.  With  the  decision  to  use 
onboard  AutoBox  processing,  the  C&DH  architecture  was  basically  set.  The  commu¬ 
nications  link  was  thereby  driven  by  the  dSPACE/AutoBox  requirements.  Thus,  the 
C  &DH / communications  architecture  determined  the  measures  related  to  data  capability, 
command  and  control,  communications  requirements,  and  the  ground  station  environment. 
These  aspects  of  performance  were  no  longer  tradable. 
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Three  performance  areas  were  identified  as  top-level  values:  Slew/Position  Perfor¬ 
mance,  Integration  Ease,  and  Experiment  Robustness.  The  measures  of  Slew/Position 
Performance  were  taken  from  the  Satellite  Movement  branch  of  the  Preliminary  Design 
VSD.  These  measures  still  allowed  system  differentiation  and  were  considered  important 
aspects  of  overall  performance.  The  Integration  Ease  branch  provided  means  to  compare 
the  technical  integration  aspects  of  the  system  alternatives.  The  Experiment  Robustness 
branch  again  included  mass  and  power  margins,  as  well  as  the  ability  to  readily  support 
thruster  integration. 

4.24.2  Cost.  The  single  measure  of  Capital  Cost,  expressed  in  dollars, 
was  used  at  this  stage.  Significant  differences  in  O&M  costs  were  not  identified  within  the 
reduced  subsystem  solution  classes  and  were  therefore  not  explicitly  considered. 

4.24.3  Slew/Position  Performance.  The  three  measures  within  this 
top-level  value  directly  correspond  to  those  of  the  Satellite  Movement  branch  of  the  Pre¬ 
liminary  Design  VSD.  Slew  Rate  Sensing  measured  the  system’s  range  of  reliable  slew  rate 
data.  Rate  Sensing  Accuracy  measured  the  system’s  accuracy  of  slew  rate  data  within  the 
system’s  reliable  data  range.  These  two  measures  were  determined  by  the  choice  of  rate 
gyros  used  on  the  satellite.  The  last  measure,  Slew  Capability,  again  was  defined  as  the 
maximum  slew  capable  within  a  lOsec  maneuver. 

4.244  Integration  Ease.  As  a  means  of  quantifying  the  ease  of  integra¬ 
tion,  Comparative  Volume  measured  the  relative  volume  of  competing  alternatives.  This 
proxy  measure  was  based  on  the  assumption  that  larger  volumes  (all  else  equal)  are  more 
difficult  to  integrate  due  to  their  size  and  decreased  modularity.  The  second  integration 
measure,  C&DH  Compatibility /Interface,  was  a  subjective  measure  to  assess  the  compat¬ 
ibility  of  alternatives  with  the  dSPACE/AutoBox  architecture.  This  measure  accounted 
for  difficulties  in  communication  and  control  of  motor  and  rate  gyro  alternatives. 

4.24.5  Experiment  Robustness.  Again,  the  Mass  Margin  and  Power 
Margin  were  identified  as  important  measures  of  SIMS  AT  performance.  A  third  measure, 
36V  Baseline  Bus  Availability,  was  a  binary  (yes/no)  indicator  of  36V  capability.  Use 
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of  this  indicator  as  a  robustness  metric  was  based  on  several  assumptions:  (1)  thrusters 
would  be  more  difficult  to  integrate  using  a  24V  maximum  capability,  (2)  a  36V  bus  would 
offer  greater  experimental  robustness,  and  (3)  a  36V  bus  would  accommodate  all  baseline 
power  requirements.  Section  4.9.5. 1,  page  4-91,  describes  the  24V  versus  36V  power  system 
rationale  in  detail. 

4.2.5  Equations-of -Motion  (EOM)  Modeling.  Before  conceptual¬ 
ization  of  momentum  wheel  alternatives  could  be  made,  EOM  modeling  was  required  to 
provide  a  system  model  allowing  exploration  and  understanding  of  momentum  wheel  per¬ 
formance.  This  model  would  be  used  to  estimate  slew  rates  of  various  system  alternatives 
for  analysis  within  this  first  Detailed  Design  iteration.  In  addition,  an  EOM  model  would 
be  useful  in  later  controller  development  and  satellite  simulation.  Appendix  B  details  the 
complete  EOM  development  used  in  this  design  iteration. 

4.2.6  System  Synthesis .  For  the  system  synthesis  step,  system  alternatives 
were  generated  to  address  the  issues  presented  in  Section  4.2.3.6.  Subsystem  alternatives 
within  each  respective  solution  class  selected  in  Preliminary  Design  were  first  considered. 
These  subsystem  alternatives  allowed  selection  on  the  system  level  of  a  preferred  momen¬ 
tum  wheel  design,  preferred  motor  type,  preferred  rate  gyro  assembly,  and  preferred  battery 
configuration.  The  dSPACE/AutoBox  C&DH  architecture  served  as  a  constraint  inherent 
in  each  system  alternative.  Additionally,  since  the  wireless  LAN  alternatives  at  this  stage 
were  similar  at  the  system  level,  a  representative  wireless  LAN  subsystem  was  used  as  a 
baseline  for  each  alternative.  Structural  configurations  were  not  addressed  explicitly  at 
this  stage  of  the  design.  The  following  paragraphs  describe  the  subsystem  alternatives 
considered  for  analysis. 

4. 2.6.1  Momentum  Wheels.  The  EOM  modeling  allowed  comparison 
of  various  momentum  wheel  configurations.  Appendix  C  describes  the  methodology  and 
analysis  of  the  momentum  wheel  sizing  problem.  The  resulting  configurations  retained 
for  system-level  analysis  are  listed  below.  As  described  in  Appendix  C,  these  alternatives 
allowed  distinct  size  versus  slew  performance  tradeoffs. 
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•  12.5”-diameter  wheels  with  an  aluminum  hoop  affixed  to  an  aluminum  disk. 

•  9”-diameter  wheels  with  a  steel  hoop  affixed  to  an  aluminum  disk. 

•  8”-diameter  wheels  with  a  steel  hoop  affixed  to  an  aluminum  disk. 

4. 2. 6. 2  Motors.  The  motors  were  required  to  drive  the  momentum 
wheels.  As  a  starting  point  in  their  selection,  several  desired  characteristics  were  defined, 
as  listed  below: 

•  Control  based  on  inputs  from  position  (or  rate)  sensors! 

•  Controlled  by  either  wheel  speed  or  torque  commands. 

•  Provide  sufficient  torque  over  the  entire  speed  range  of  the  motor. 

•  Use  of  a  DC  power  supply. 

•  Based  on  initial  figures,  need  a  continuous  torque  of  at  least  150  oz-in. 

•  Maximize  the  peak  torque. 

•  Minimize  the  motor’s  size  and  weight. 

The  first  three  characteristics  were  used  to  determine  the  required  motor  type  for  the 
SIMS  AT  application,  using  the  Motor  Selection  Guide  in  the  Oriental  Motor  General 
Catalog  [41:12].  One  solution  class  emerged:  brushless  DC  motors.  According  to  the 
manual,  these  motors  provided  sufficient  torque  across  the  entire  speed  range,  could  be 
operated  by  speed  control,  and  could  be  controlled  based  on  inputs  from  position  (or  rate) 
sensors. 

While  research  indicated  a  wide  variety  of  brushless  DC  motors  were  available,  there 
were  surprisingly  few  choices  which  met  the  general  requirements  of  the  design.  Due  to 
high  power  requirements,  insufficient  torque  values,  unacceptable  physical  dimensions,  or 
excessive  mass  requirements  (based  on  an  initial  18kg  mass  budget  for  the  AD  ACS' subsys¬ 
tem),  many  alternatives  were  eliminated.  Dr.  Chris  Hall,  a  noted  specialist  in  the  area  of 
space  systems  design  and  spacecraft  attitude  and  determination  control,  recommended  the 
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Animatics  SmartMotor  series  to  the  design  team.  Dr.  Hall  had  used  the  SmartMotor  series 
in  his  previous  momentum  wheel  research  due  to  their  flexibility  and  programmability. 

In  addition  to  satisfying  performance  requirements,  the  SmartMotor  has  an  internal 
memory  chip  within  its  controller  which  stores  various  control  programs.  Depending  on 
the  application,  the  program  could  be  changed  prior  to  an  experiment  to  change  the  char¬ 
acteristics  of  the  motor.  This  capability  was  initially  determined  to  be  of  possible  use  in 
SIMS  A  T  operation. 

Based  on  the  available  information,  one  SmartMotor  (model  3450)  was  purchased 
for  research  and  testing  through  Servo  Systems,  Co.,  of  Montville,  NJ.  With  end-of-year 
funds  available,  this  short-notice  purchase  would  allow  insight  into  the  SmartMotor  before 
ordering  all  three  motors.  Other  laboratory  uses  of  the  motor  were  intended  should  the 
motor  prove  to  be  unacceptable  or  less  desired  for  SIMSAT  application.  Table  4.2  shows 
some  of  the  characteristics  of  the  SmartMotor.  The  SmartMotor’s  parameters  were  used 
to  provide  a  general  motor  model  for  the  Matlab  code  used  in  the  EOM  modeling  (see 
Appendix  B). 


Table  4.2  SmartMotor  Characteristics  [51] 


Parameter 

Value 

Peak  Torque 

750  oz-in 

Continuous  Torque 

250  oz-in 

Voltage  Constant 

13.7V/krpm 

No  Load  Speed 

3398  RPM 

Torque  Constant 

18.5  oz-in/Amp 

Rotor  Inertia 

0.025  oz-in-sec2 

Weight 

3.47  kg 

Number  of  Poles 

4 

Number  of  Slots 

24 

Length 

6.088  in 

Once  the  SmartMotor  was  delivered,  more  knowledge  was  gained  on  the  interface 
issues  between  the  AutoBox  and  the  SmartMotor.  It  became  apparent  that  intermediate 
components  would  be  needed  to  allow  the  AutoBox  to  control  the  motor.  In  particular,  the 
outgoing  signal  from  the  AutoBox  was  an  analog  signal.  The  SmartMotor  was  primarily 
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designed  for  a  digital  signal.  To  properly  convert  the  signal,  an  Animatics  1/0-116  analog 
card  was  needed  to  convert  the  ±5V  analog  input  signal  to  a  16-bit  digital  signal.  Addi¬ 
tionally,  to  read  wheel  speed  information  from  the  motor,  a  velocity  reader  chip  attached  to 
the  SmartMotor’s  encoder  was  needed  to  provide  an  analog  input  to  the  Autobox.  Due  to 
these  requirements,  the  complexity  of  the  system  was  significantly  greater  than  originally 
anticipated. 

Since  the  SmartMotor  was  initially  designed  as  a  stand-alone  system,  it  did  not 
integrate  well  with  other  controllers  performing  the  same  function  (such  as  the  AutoBox 
processor).  By  purchasing  I/O  cards  and  velocity  reader  chips,  the  SmartMotor  controller 
would  essentially  be  bypassed. 

Through  discussions  with  Mr.  Edmund  Kong,  a  technical  support  representative  at 
Animatics,  an  alternative  solution  appeared.  A  different  motor,  the  BL-3450,  did  not  use 
the  integrated  controller  and  amplifier  of  the  SmartMotor,  but  provided  similar  perfor¬ 
mance.  Its  characteristics  are  shown  in  Table  4.3.  This  motor  offered  the  simplicity  of 
a  direct  connection  to/from  the  AutoBox  through  an  amplifier.  Additionally,  since  the 
motor’s  parameters  were  identical  to  the  SmartMotor,  the  Matlab  code  used  for  EOM 
modeling  required  no  modifications. 

Table  4.3  “Dumb”  Motor  Characteristics  [51] 


Parameter 

Value 

Peak  Torque 

750  oz-in 

Continuous  Torque 

250  oz-in 

Voltage  Constant 

13.7V/kRPM  j 

No  Load  Speed 

3398  RPM 

Torque  Constant 

18.5  oz-in/Amp 

Rotor  Inertia 

0.025  oz-in-sec2 

Weight 

3.27  kg 

Number  of  Poles 

4 

Number  of  Slots 

24 

Length 

6.088  in 
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Both  the  Animatics  SmartMotor  3450  and  Animatics  BL-3450  (referred  to  as  the 
“smart”  motor  and  “dumb”  motor,  respectively)  were  considered  in  system-level  analysis 
in  this  design  iteration,  as  neither  model  was  superior  in  all  performance  measures. 

4. 2.6. 3  Momentum  Wheel  Safety.  As  described  previously,  enclosure 
of  the  momentum  wheels  was  required  to  protect  against  equipment  damage  or  personnel 
injury  should  a  loose  part  contact  a  rotating  wheel  or  a  motor  shaft  catastrophically  fail. 
It  was  desired  that  this  enclosure  be  strong  enough  to  provide  safety  benefits,  yet  light 
enough  to  minimize  weight  penalties.  Furthermore,  a  clear  enclosure  would  allow  visual 
observation  of  the  momentum  wheels  during  operation,  enhancing  the  teaching  utility  of 
the  system  and  allowing  for  monitoring  of  the  motors  and  wheels.  It  was  decided  that 
lexan  would  be  a  logical  choice  for  such  an  application.  This  strong,  clear  material  was 
readily  available  from  a  local  supplier,  Dayton  Plastics  of  Dayton,  OH.  Further  evaluation 
of  the  momentum  wheel  enclosure  was  determined  to  be  of  little  value,  as  the  lexan  solution 
satisfied  all  requirements. 

4. 2. 6. 4  Rate  Gyros.  Internet  resources,  as  well  as  discussions  with 
Capt.  Agnes  and  Mr.  Anderson  of  AFIT/ENY,  were  used  to  research  gyro  alternatives. 
The  main  problem  with  finding  an  adequate  gyro  for  SIMS  AT  was  that  most  gyros  are 
built  for  a  specific  application.  Commercially-available  gyros  are  often  used  for  small 
applications  such  as  model  airplanes  and  model  helicopters.  While  these  alternatives  were 
relatively  inexpensive  (under  $200  per  gyro),  the  accuracy  of  these  systems  was  unknown. 
At  the  other  extreme,  space-rated  systems  offered  excellent  accuracy  capability  with  small 
drift  rates.  However,  the  cost  of  these  systems  was  deemed  infeasible.  As  a  compromise, 
the  gyros  used  with  full-size  aircraft  (such  as  helicopters)  provided  a  middle  ground  in 
both  the  cost  and  performance  for  this  design  application. 

After  researching  the  alternatives,  two  systems  were  identified  and  purchased  with 
fallout  money  at  the  end  of  FY98.  The  NEJ-3000  Piezo  Gyro,  developed  by  JR  Propo, 
fell  within  the  model  helicopter  category.  Based  on  information  from  model  helicopter 
resources,  this  rate  gyro  was  the  best  model  helicopter  gyro  available  with  respect  to  drift 
rates  and  operating  ranges.  However,  to  integrate  the  gyro  successfully,  additional  servos 
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were  needed  to  provide  the  power  and  reference  signal  for  the  gyro  ($20-$50  per  servo). 
Since  technical  support  was  provided  by  the  Horizon  Service  Center  in  Champaign,  IL, 
this  alternative  was  labeled  the  Horizon  gyro  within  this  design  iteration.  The  Horizon 
gyro  specifications,  provided  by  the  manufacturer,  are  shown  in  Table  4.4. 

Table  4.4  NEJ-3000  Characteristics 


Parameter 

Value 

Operating  Voltage 

4.8V 

Operating  Current 

0.05A 

Weight 

0.037  kg 

Slew  Rate  Range 

±720  deg/sec 

Half  Range  Accuracy 

7.2  deg/sec' 

Pull  Range  Accuracy 

28.8  deg/sec 

The  second  alternative,  the  CF75  Series  Axis  rate  gyro,  was  developed  by  Humphrey, 
Inc.,  located  in  San  Diego,  CA.  In  addition  to  being  a  three-axis  rate  gyro  used  on  full-size 
helicopters,  the  CF75  also  included  linear  accelerometers  that  could  be  used  for  more  pre¬ 
cise  position  measurements.  Additionally,  unlike  the  Horizon  gyro,  the  rate  ranges  were 
not  pre-determined  and  could  be  adjusted  to  fit  the  needs  of  SIMS  AT  during  develop¬ 
ment2.  This  alternative  was  also  more  expensive  than  the  Horizon  gyro.  Table  4.5  lists 
the  Humphrey  gyro  specifications  provided  by  the  manufacturer  and  the  selected  sensing 
ranges. 


4* 2. 6. 5  Battery  Configurations.  Using  the  sealed  lead  acid  battery 
solution  class,  battery  vendors  were  first  considered.  Based  on  technical  data  regard¬ 
ing  specifications  and  performance,  the  Power-Sonic  line  of  sealed  lead  acid  batteries  was 
chosen  as  the  baseline  for  power  subsystem  development.  Power-Sonic  products  were  dis¬ 
tinguished  by  their  high  discharge  rate  compared  to  other  lead  acid  batteries;  low  internal 
resistance  allows  discharge  currents  of  up  to  ten  times  the  rated  capacity  of  the  battery. 
Additionally,  the  use  of  special  separators,  advanced  plate  composition,  and  a  finely  bal¬ 
anced  electrolyte  system  greatly  improves  the  ability  of  Power-Sonic  batteries  to  recover 

2 See  Appendix  D  for  a  description  of  the  gyro  range  determination. 
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Table  4.5  Humphrey  CF75  Characteristics 


Parameter 

Value 

Operating  Voltage 

28±4V 

Operating  Current 

0.58A 

Weight 

1.05  kg 

Roll  Rate  Range 

±120  deg/sec 

Roll  Accuracy  (Half  Range) 

1.2  deg/sec 

Roll  Accuracy  (Full  Range) 

4.8  deg/sec 

Pitch/Yaw  Rate  Range 

±40  deg/sec 

Pitch/ Yaw  Accuracy  (Half  Range) 

0.6  deg/sec 

Pitch/Yaw  Accuracy  (Full  Range) 

2.4  deg/sec 

from  excessively  deep  discharge  [43].  The  availability  and  wide  range  of  batteries  also 
justified  the  decision  to  use  Power-Sonic  products. 

The  next  step  in  determining  battery  alternatives  was  to  select  appropriately  sized 
batteries.  The  capacity  of  a  battery  is  the  total  amount  of  electrical  energy  available  from 
the  fully  charged  cell(s).  Battery  capacity  depends  on  the  discharge  current,  temperature 
during  discharge,  final  cut-off  voltage,  and  general  battery  history.  Capacity,  expressed  in 
Ampere-hours  (Ahr)  is  the  product  of  the  current  discharged  and  the  length  of  discharge 
time.  The  rated  capacity  of  a  battery  is  measured  by  its  performance  over  20  hours  of 
constant  current  discharge  at  a  temperature  of  20  degrees  Celsius  to  a  cut-off  voltage  of 
1.75  volts.  For  a  battery  discharging  at  a  constant  rate,  its  capacity  changes  according  to 
the  system  load.  Capacity  increases  when  the  discharge  current  is  less  than  the  20  hour 
rate,  and  decreases  when  the  current  is  higher. 

To  choose  the  appropriately  sized  battery  capacity  for  SIMSAT  use,  a  hypothetical 
power  profile  was  established  for  basic  sizing  estimates.  “Worst-case”  values  were  obtained 
by  assuming  maximum  power  draw  (full  load  on  all  components)  for  the  longest  possible 
experiment  length.  With  the  bus  voltage  specified  as  24V  or  36V,  the  required  battery 
capacity  was  determined  using  logarithmic  sizing  graphs  provided  by  Power-Sonic.  For 
example,  assuming  a  constant  discharge  current  of  10A  for  one  hour,  an  18-Ahr  battery 
provides  the  required  power  (rather  than  the  10- Ahr  value  suggested  by  strict  dimensional 
analysis).  In  this  way,  various  combinations  of  Power-Sonic  batteries  were  selected,  with 
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both  24V  and  36V  alternatives  considered.  These  five  battery  alternatives  are  displayed 
in  Table  4.6. 


Table  4.6  Battery  Configuration  Alternatives 


Alternative 

Designator 

Battery 

Setup 

Rated 

Capacity 

Amps  at 
0.5C  rate 
(1.3  hr) 

Actual 
Capacity 
(1.3  hr) 

Amps  at 
1.0C  rate 
(33  min) 

Actual 
Capacity 
(33  min) 

3-batt-18 

3  Batteries 
18  Ahr 

54  Ahr 
(36V) 

27 

35.1  Ahr 

54 

29.7  Ahr 

3-batt-12 

3  Batteries 
12  Ahr 

36  Ahr 
(36V) 

18 

23.4  Ahr 

36 

20.2  Ahr 

3-bat  t- 10 

3  Batteries 
10  Ahr 

30  Ahr 
(36V) 

15 

19.5  Ahr 

30 

16.8  Ahr 

2-batt-18 

2  Batteries 
18  Ahr 

36  Ahr 
(24V) 

18 

23.4  Ahr 

36 

19.8  Ahr 

2-batt-12 

2  Batteries 
12  Ahr 

24  Ahr 
(24V) 

12 

15.6  Ahr 

24 

13.4  Ahr 

4. 2. 6. 6  Wireless  LAN.  As  stated  previously,  a  baseline  wireless  LAN 
system  was  used  for  each  system  alternative.  Based  on  initial  research3,  only  two  COTS 
wireless  LAN  systems  were  available  to  meet  the  10Mbps  Ethernet  specification  required 
for  dSPACE/AutoBox  communications.  Aironet  Wireless  Communications,  Inc.,  of  Akron, 
OH,  offered  the  11Mbps  Aironet  4800  Turbo  DS  Series  as  of  1  December  1998  [2].  The 
AP4800  uses  2.4GHz  RF  transmission  at  lOOmW  transmission  power,  with  a  Type  II  PC- 
card  interface.  System-level  specifications  included  a  12V  power  supply  at  1.5 A,  0.7kg 
mass,  and  dimensions  of  20cm  x  15cm  x  5cm.  The  second  alternative  was  produced  by 
RadioLAN  of  Sunnyvale,  CA  [45].  RadioLAN’s  ISA  CardLINK  system  offered  10Mbps 
Ethernet  connectivity  using  5.8GHz  transmission  at  50mW  output.  System-level  specifi¬ 
cations  included  12V  power  supply  at  50mA  (or  5V  at  500mA)  for  the  ISA  interface  card, 
0.5kg  mass,  and  dimensions  of  18cm  x  7cm  x  4cm.  Thus,  both  systems  offered  comparable 
performance  and  physical  specifications.  As  they  were  also  similarly  priced,  they  offered 
similar  system-level  interactions,  justifying  the  selection  of  a  wireless  LAN  model  as  a 
separate  subproblem  to  be  addressed  in  later  design. 

3Detailed  wireless  LAN  specifications  axe  described  in  Section  4.8,  page  4-80. 
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For  this  design  iteration,  RadioLAN’s  ISA  CardLINK  was  chosen  as  a  baseline  for 
all  system  alternatives.  This  model  was  available  at  the  time  this  design  iteration  was 
accomplished  (unlike  the  Aironet  4800  model),  prompting  its  choice  as  a  baseline. 


4-2.6. 7  Alternatives  Summary.  Table  4.7  shows  the  subsystem  alter¬ 
natives  used  to  generate  system  alternatives  for  analysis  in  this  phase.  System  alternatives 
were  constructed  using  the  full-factorial  combinations  of  the  subsystem  alternatives.  Thus, 
a  total  of  60  system  alternatives  were  considered. 

Table  4.7  Detailed  Design  Subsystem  Alternatives 


Subsystem 

Alternatives 

Attitude  Determination 

Humphrey  Gyros 

Horizon  Gyros 

Attitude  Control 
(Momentum  Wheels) 

Aluminum  Hoop/Aluminum  Disk  (12.5”-dia.) 
Steel  Hoop/Aluminum  Disk  (9”-dia.) 

Steel  Hoop/Aluminum  Disk  (8”-dia.) 

Attitude  Control 

“Smart”  Motors 

(Motors) 

“Dumb”  Motors 

Power 

3  Batteries  (18  Ahr) 

3  Batteries  (12  Ahr) 

3  Batteries  (10  Ahr) 

2  Batteries  (18  Ahr) 

2  Batteries  (12  Ahr) 

C&DH 

Onboard  AutoBox  Processing 

Communications 

RadioLAN  (Wireless  Baseline) 

Structures 

As  Required 

4' 3  First- Iteration  Analysis 

4-3.1  System  Modeling.  The  following  sections  describe  the  system  mod¬ 
eling  used  to  evaluate  each  measurable  of  the  objective  hierarchy  (Figure  4.2). 

4.3. 1.1  Capital  Cost.  This  measurable  was  assessed  through  summa¬ 
tion  of  the  subsystem  costs  for  each  alternative.  With  the  narrowed  system  configurations, 
integration  costs  were  considered  to  be  similar  for  each  system  alternative,  and  were  thus 
not  included  in  this  measurable.  Furthermore,  costs  associated  with  the  in-house  manu- 
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facturing  of  the  momentum  wheel  designs,  using  the  AFIT  fabrication  shop,  were  also  not 
included.  The  baseline  costs  of  the  AutoBox  and  wireless  communications  were  also  not 
included,  as  these  costs  were  common  to  all  configurations.  At  this  stage  of  the  design, 
both  rate  gyro  systems  were  purchased  (using  “fallout”  funds  from  FY98).  Rate  gyro  costs 
were  therefore  not  included  in  the  Capital  Cost  measure  since  these  costs  were  considered 
unrecoverable  for  either  gyro  alternative.  Thus,  the  motors  and  batteries  comprised  the 
Capital  Cost  measure. 

4.3. 1.2  Slew  Rate  Sensing.  This  measure  was  assessed  using  the  slew 
rate  ranges  given  by  the  rate  gyro  specifications,  measured  in  deg/sec.  Thus,  this  measure 
was  gyro-dependent. 

4. 3. 1.3  Rate  Sensing  Accuracy.  Like  Slew  Rate  Sensing ,  this  measure 
was  based  on  gyro  capabilities.  A  resolution  of  low  (poor  sensing  range),  medium  (adequate 
sensing  range),  and  high  (good  sensing  range)  was  used  to  model  the  relative  accuracy  of 
the  gyro  alternatives  based  on  their  intended  applications  and  performance  specifications. 

4. 3. 1.4  Slew  Capability.  A  Matlab  simulation,  based  on  the  EOM 
modeling  of  Appendix  B,  was  used  to  estimate  maximum  slew  maneuvers  in  a  lOsec  period. 
Since  the  motor  alternatives  had  comparable  weight  and  torque  capabilities,  this  measure 
was  considered  independent  of  the  motor  selection.  Moreover,  the  choice  of  battery  size 
had  negligible  effects  on  slew  performance  since  battery  mass  was  a  small  percentage  of 
total  system  weight.  However,  the  choice  between  a  two-  or  three-battery  configuration 
significantly  impacted  slew  maneuvers  since  motor  outputs  differed  for  a  24V  system  versus 
a  36V  system.  The  choice  of  momentum  wheel  configuration  also  impacted  this  measure, 
as  the  momentum  wheels  provide  the  necessary  slewing  torques. 

4. 3. 1.5  Comparative  Volume.  This  proxy  measure  of  structural  mod¬ 
ularity  did  not  include  the  gyros  or  motors,  as  the  relative  volumes  of  alternatives  were 
similar.  Thus,  volume  differences  between  system  configurations  were  dependent  on  the 
choice  of  battery  configuration  as  well  as  the  choice  of  momentum  wheel  design.  The  wheel 
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volumes  assumed  a  1/4”  (thick)  lexan  box  with  1/2”  clearance  on  each  side  enclosing  each 
momentum  wheel. 

4. 3. 1.6  C&DH  Compatibility/Interface.  This  subjective  measure 
was  modeled  using  the  assumption  that  non-dSPACE  control  software  (inherent  in  the 
smart  motors)  would  be  difficult  to  circumvent.  The  experience  with  the  smart  motor 
showed  that  this  condition  was  indeed  the  case4.  The  gyro  compatibility  with  the  AutoBox 
was  also  considered  in  the  mental  modeling  of  this  measure.  The  following  resolution  was 
used  in  the  evaluation  of  this  measure: 

•  Low.  Significant  interface  challenges  (in  number  or  magnitude)  were  anticipated. 

•  Medium.  Some  interface  challenges  were  anticipated. 

.  High.  Few,  if  any,  significant  interface  challenges  were  anticipated. 

4*3.1. 7  Mass  Margin.  A  maximum  system  weight  of  3001b  was  used  to 
determine  this  margin.  The  weight  of  all  components,  including  representative  thrusters, 
was  subtracted  from  this  3001b.  Thus,  this  measure  represents  the  maximum  payload  mass 
supportable  by  the  system.  Because  the  structure  was  as  yet  undetermined,  the  mass  of  all 
components  was  increased  30%  for  each  configuration  to  account  for  structural  weight  and 
cabling.  Lexan  boxes  (1/4”  thick)  were  included  in  the  mass  of  the  momentum  wheels. 

4-3. 1.8  Power  Margin.  This  measure  was  defined  as  available  payload 
power,  measured  in  Watts.  The  total  power  consumption  of  each  alternative  was  subtracted 
from  the  total  power  output  of  each  battery  configuration.  Power  consumption  was  based 
on  performance  specifications,  motor  models,  and,  in  the  case  of  the  AutoBox,  actual 
experimental  data5. 

4The  motor  purchased  in  FY98  was  controllable  using  the  supplied  PC-based  control  software,  but  inte¬ 
gration  with  dSPACE  would  require  this  software  to  be  bypassed.  Conversation  with  Animatics  engineers 
revealed  that  this  design  problem  was  not  trivial. 

5Using  an  external  DC  power  source,  the  AutoBox  was  shown  to  draw  approximately  60W  in  the 
laboratory,  significantly  less  than  the  135W  peak  power  specification. 
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4.3. 1.9  36V  Baseline  Bus  Availability.  This  binary  measure  was 

modeled  as  “yes”  for  36V  battery  configurations,  and  “no”  for  24V  configurations. 

4-3.2  Raw  Values.  The  raw  values  for  all  60  system  configurations  are 
shown  in  Appendix  F,  Tables  F.l  and  F.2. 

4 .3. 3  Utility  Scaling.  The  next  step  in  the  system  evaluation  of  these  alter¬ 
natives  was  to  determine  a  common  utility  scale  for  each  measure.  As  in  the  Preliminary 
Design  phase,  a  scale  ranging  from  0  (no  utility)  to  10  (excellent  utility)  was  used.  Direct 
inputs  from  the  decision  maker  were  used  to  construct  the  utility  scale  for  each  measure. 
These  inputs  are  summarized  in  Figure  4.3.  For  each  system  alternative,  the  raw  values 
for  each  measurable  were  scaled  using  these  utility  functions. 


Objective  Measurable  0 

Capital  Costs 

Slew  Rate  Sensing  (deg/s  range) 


Rate  Sensing  Accuracy 
Slew  Capability  (deg/s  avg  *  1 0s) 
Comparative  Volume  (inA3) 


CDH  Compatibility/Interlace 
Mass  Margin  (kg) 

Power  Margin  (W)  0 

36V  Bus  Availability 


Utility  Scale 
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Figure  4.3  Detailed  Design  Utility  Scale 


4-4  First-Iteration  Interpretation 

4 -4-1  Weighting  Factors.  In  order  to  convert  scaled  scores  into  system 

scores,  the  measurables  were  weighted  using  inputs  from  the  decision  makers.  A  judgement 
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matrix  approach  was  used  to  generate  an  initial  weighting  factors  vector.  Prom  this  resul¬ 
tant  vector,  the  decision  maker  modified  the  weighting  factors  for  use  in  system  ranking 
and  selection. 

44-1.1  Judgement  Matrix  Approach.  As  described  by  Sage  [49], 
weighting  factors  can  be  determined  through  a  one-to-one  comparison  of  importance  for 
all  measures.  This  comparison,  made  by  the  decision  maker,  results  in  a  matrix  of  relative 
importance,  referred  to  as  a  judgement  matrix.  For  each  measurable,  a  geometric  mean  of 
the  relative  importance  “scores”  across  every  other  measurable  can  be  computed.  These 
geometric  means  are  then  normalized  to  produce  initial  weighting  factors. 

For  this  design  iteration,  the  judgement  matrix  shown  in  Figure  4.4  was  considered 
by  the  decision  maker.  This  figure  shows  the  scale  used  in  importance  estimation,  the 
decision  maker  inputs,  and  the  resulting  weighting  factors. 


4-4-1-2  Weighting  Factor  Refinements.  The  decision  maker  refined 
the  weighting  factors  developed  in  the  judgement  matrix  approach  to  better  reflect  the 
level  of  importance  of  each  measure.  The  weighting  factors  vector  used  in  system  scoring 
is  listed  in  Table  4.8. 


Table  4.8  Ranked  Weighting  Factors 


Measurable 

Weighting  Factor 

Mass  Margin 

0.20 

Power  Margin 

0.20 

Slew  Capability 

0.20 

Slew  Rate  Sensing 

0.10 

Rate  Sensing  Accuracy 

0.10 

CDH  Compatibility/Interface 

0.08 

Capital  Cost 

0.04 

Comparative  Volume 

0.04 

36V  Baseline  Bus  Availability 

0.04 

Components  Sum 

1.000 
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JUDGEMENT  MATRIX  DETERMINATION  OF  WEIGHTING  FACTORS 
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Judgement  matrix  is  ” reciprocal-symmetric " 


RELATIVE  IMPO  RTANCE  SCALE:  9  =  A  is  so  important  that  B  has  little,  if  any,  relative  value 

7  =  A  substantially  more  important  than  B 
5  =  A  significantly  more  important  than  B 
3  =  A  slightly  more  important  than  B 
1  =  A  and  B  are  comparable 
1/3  =  B  slightly  more  important  than  A 
1/5  =  B  significantly  more  important  than  A 
1/7  =  B  substantially  more  important  than  A 
1/9  =  B  is  so  important  that  A  has  little,  if  any,  relative  value 


Figure  4.4  Objectives  Judgement  Matrix 


System  Ranking  and  Selection .  The  scaled  scores  for  each  system 
alternative  were  normalized  and  multiplied  by  the  weighting  factors  vector  to  determine 
system  scores  for  each  alternative.  These  system  scores  were  ranked,  as  shown  in  Ap¬ 
pendix  F,  Table  F.3.  Slight  adjustments  to  the  weighting  factors  did  not  alter  the  top 
choices  significantly.  With  just  nine  measurables  to  consider,  the  decision  maker  was  com¬ 
fortable  with  the  weighting  factors  (they  were  direct  in  that  no  branch  weights  diluted 
important  measures);  thus,  an  in-depth  sensitivity  analysis  was  deemed  to  provide  little 
added  value.  From  these  system  rankings,  subsystem  conclusions  were  made. 


4'4>%*1  Motors .  In  general,  “dumb”  motor  alternatives  ranked  over 

“smart”  motor  alternatives.  This  result  was  logical  since  both  motors  produced  comparable 
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torques,  yet  the  smart  motors  were  more  expensive  and  difficult  to  interface  with  the 
AutoBox  solution.  These  drawbacks  more  than  offset  the  weight  savings6  of  the  smart 
motors.  Dumb  motors  were  chosen  for  continued  design. 

4. 4 -2. 2  Momentum  Wheels.  The  9”  momentum  wheels  scored  higher 
for  comparable  alternatives.  Based  on  the  weighting  factors,  this  result  was  due  to  the 
compromise  of  lower  slew  rates  relative  to  the  12.5”  wheels  for  less  weight  and  volume 
penalties.  Alternatively,  the  9”  wheels  gave  enough  performance  advantage  to  offset  the 
increased  weight  and  volume  relative  to  the  8”  wheels.  Thus,  a  9”  momentum  wheel  design 
was  considered  for  further  development. 

4. 4. 2. 3  Rate  Gyros.  The  rate  gyros  did  not  provide  much  scoring 
differentiation,  with  the  Humphrey  model  scoring  slightly  higher  than  the  Horizon  model. 
Before  a  decision  was  made,  the  Horizon  model,  designed  for  radio-control  helicopters 
with  a  radio-control  interface,  was  hooked  up  to  an  oscilloscope  within  the  laboratory  to 
better  determine  its  signal  data.  Without  complete  signal  documentation,  these  rate  gyros 
were  difficult  to  analyze.  Additional  system  description  was  sought  from  the  manufacturer 
with  little  results.  The  Humphrey  models  provided  more  complete  documentation  and 
were  considered  less  risky  to  integrate.  Thus,  the  Humphrey  models  were  chosen  for 
continued  design.  Should  future  problems  warrant,  the  Horizon  models  were  still  available 
for  implementation. 

4.4.2. 4  Battery  Configuration.  The  3-battery  alternative  with  18- 
Ahr  batteries  ranked  atop  the  system  alternatives.  This  alternative  provided  the  greatest 
power  availability  which,  upon  system-level  analysis,  more  than  offset  the  additional  cost 
and  mass.  This  alternative  was  selected  for  SIMS  AT  implementation. 

4.4 ‘3  Implementation.  The  resulting  system  architecture  is  described  in 
Table  4.9.  This  architecture  served  as  the  baseline  for  the  Detailed  Design  subproblems 
addressed  further  in  this  design  phase. 

6Smart  motors  included  controller  software  whereas  dumb  motors  required  an  additional  amplifier 
interface. 
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Table  4.9  Detailed  Design  Resulting  Architecture 


Subsystem 

Detailed  Design  Decision 

Attitude  Determination 

Humphrey  Rate  Gyros 

Attitude  Control 
(Momentum  Wheels) 

Steel  Hoop/ Aluminum  Disk 
(9”  outer  diameter) 

Attitude  Control 
(Motors) 

“Dumb”  Motors 
with  Amplifiers 

Power 

3  Batteries  (18  Ahr) 

C&DH 

Onboard  AutoBox  Processing 

Communications 

COTS  Wireless  LAN/Modem 

Structures 

As  Required 

The  first  step  in  the  implementation  of  this  architecture  was  to  deliver  momentum 
wheel  designs  to  the  AFIT  fabrication  shop.  Based  on  the  shop’s  on- hand  supplies,  the  mo¬ 
mentum  wheel  sizes  were  slightly  adjusted  to  accommodate  quicker  manufacturing.  With 
the  selection  of  the  dumb  motor  option,  three  Animatics  BL-3450  motors  and  accompa¬ 
nying  amplifiers  were  ordered  for  the  momentum  wheel  assembly.  Power-Sonic  18-Ahr 
batteries  were  also  ready  for  order  at  this  time.  A  total  of  six  batteries  were  procured; 
three  for  operation  and  three  as  spares,  allowing  complete  swapping  of  batteries  during 
experimentation  without  any  recharge  downtime. 

At  this  stage,  further  design  issues  were  formulated  to  progress  to  a  final  design. 
With  the  narrowing  of  the  system  architecture,  detailed  subsystem  design  could  be  accom¬ 
plished  without  the  need  to  make  complete  system  alternative  comparisons,  as  done  in  the 
previous  design  iterations.  Subsystem  design  was  accomplished  on  a  system-level  through 
the  consideration  of  subsystem  interfaces,  system  impacts,  and  subsystem  integration.  The 
following  list  of  subproblems  was  identified  for  further  detailed  design: 


•  Development  of  the  controller  and  command  interface. 

•  Development  of  a  baseline  structural  design. 

•  Calculation  of  static  and  dynamic  structural  deflections  under  loading. 

•  Selection  of  wireless  communications  vendors. 

•  Subsystem  integration,  to  include  signals  and  power. 
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•  Design  of  a  safety  system  for  SIMS  AT  operation. 

•  Consideration  of  thruster  integration. 

The  remaining  portion  of  the  Detailed  Design  chapter  specifically  addresses  the  systems 
approach  to  these  subproblems. 

4.5  Command  and  Control  Architecture 

4-5.1  Problem  Statement.  In  the  preliminary  design  phase,  several  deci¬ 
sions  were  made  that  affected  the  direction  of  command  and  control  development  in  the 
Detailed  Design  phase.  Since  dSPACE  software  was  selected  for  C&DH  functions,  and 
the  method  of  attitude  determination  and  control  was  chosen,  actual  coding  of  SIMS  AT 
control  software  could  begin.  The  problem  statement  dealing  specifically  with  the  software 
architecture  was: 

Based  on  the  AD  ACS  and  C&DH  system  architectures  developed  in  the  Preliminary 
Design  phase,  design  the  software  control  laws  and  user  interface(s)  to  meet  requirements 
for  SIMSAT  operations. 

4-5.2  Command  and  Control  Issues.  From  the  Preliminary  Design 
phase,  the  system  architecture  included  an  ADACS  subsystem  consisting  of  momentum 
wheels  and  rate  gyros  and  a  C&DH  subsystem  employing  full  onboard  processing  using 
the  dSPACE  AutoBox.  This  Detailed  Design  iteration  concerns  the  process  of  developing 
control  laws  for  integration  with  ADACS  and  C&DH. 

Based  on  the  system  needs,  the  following  issues  involving  command  and  control 
development  needed  to  be  addressed  to  design  a  final  product: 

•  It  was  necessary  to  determine  an  appropriate  method  of  providing  control  to  the 

ADACS  hardware  in  order  to  meet  performance  requirements. 

•  To  safely  test  the  control  law  design  off-line,  and  allow  off-line  simulations  of  system 

performance,  a  model  of  the  SIMSAT  plant  dynamics  was  needed. 
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•  Development  of  a  user  interface  was  required  to  provide  command  and  control  inputs 
to  SIMS  AT. 

•  A  method  of  displaying  real-time  and  post- test  data  from  SIMS  AT  operations  was 
essential  to  provide  user  feedback  and  allow  experiment  analysis. 

•  While  managing  the  above  issues,  maintaining  ease-of-use  and  user-friendliness  of 
the  ground  station  architecture  was  also  necessary. 

•  Finally,  the  software  architecture  needed  to  be  robust  to  allow  future  modifications 
for  yet  undetermined  experiments. 

4  *5. 3  Value  System  Design.  To  address  these  design  issues,  the  following 
list  of  objectives  was  used  in  the  development  of  the  user  interface  and  control  laws: 

•  Ensure  control  law  compatibility  with  the  dSPACE  software. 

•  To  enhance  control  law  processing,  minimize  extraneous  software  coding. 

•  Minimize  the  text-based  software  coding  required  for  control  law  development  to 
allow  easier  and  quicker  development. 

•  Maximize  user  friendliness  through  graphical  methods  to  enhance  command  capabil¬ 
ity  and  real-time  data  display. 

•  To  allow  control  logic  modifications,  maximize  robustness  of  the  control  law  devel¬ 
opment. 

•  Minimize  additional  costs  incurred  in  software  architecture  development. 

4 ‘5. 4  Development  Approach.  Based  on  the  objectives,  several  design 
decisions  were  immediately  apparent.  To  start,  MATLAB-based  software  was  chosen  as  the 
primary  control  law  development  tool.  This  software  was  compatible  with  the  dSPACE 
software  (Matlab/Simulink  interfaces  were  inherent  in  the  dSPACE  control  architecture) 
and  incorporated  built-in  control  toolboxes  and  optimization  routines.  Matlab  and  Simu- 
link  were  also  readily  available  at  AFIT,  and  the  design  team  had  significant  programming 
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expertise  with  this  software.  Although  C-coding  could  be  used  directly  by  dSPACE,  Mat- 
lab/Simulink  was  easier  to  use  and  compiled  to  C-code.  The  Cockpit  and  Trace 
software  provided  the  primary  command  and  data  display  capabilities.  These  software 
packages  were  also  dSPACE-compatible  and  already  available  with  the  dSPACE  system. 
Likewise,  RealMotion  was  the  preferred  animation  software,  as  it  was  also  provided  with 
the  dSPACE  system  and  allowed  excellent  graphical  animation  capability. 

The  basic  approach  to  developing  the  command  and  control  software  architecture 
involved  the  following  steps.  First,  a  satisfactory  mathematical  model  was  created  to 
simulate  SIMSAT  behavior  during  off-line  simulations.  Next,  the  control  laws  needed 
to  operate  the  system  according  to  requirements  were  established.  Once  a  simulation 
demonstrating  desired  SIMSAT  performance  was  developed,  it  was  converted  for  download 
to  the  AutoBox.  Finally,  the  software  links  required  to  provide  graphical  command  and 
control,  telemetry  analysis,  and  3-D  motion  simulation  were  developed. 

Specifically,  mathematical  models  were  developed  for  the  SIMSAT  “plant”  and  con¬ 
trollers.  Once  these  dynamic  models  were  understood,  the  equations  were  coded  into 
Matlab  software.  This  Matlab  program  was  then  used  to  simulate  the  control  laws. 
For  real-time  applications,  and  off-line  simulations  using  the  AutoBox,  these  models  were 
coded  in  Simulink  (based  on  the  Matlab  code),  a  part  of  the  dSPACE  software  suite. 
The  dSPACE  software  then  compiled  this  code  to  a  working  application  and  downloaded  it 
to  AutoBox.  The  Cockpit  and  Trace  applications  within  the  dSPACE  suite  were  then 
used  to  create  the  “virtual”  ground  station. 

4-5.5  Plant  Model.  Equations  of  motion  were  developed  to  create  a  dy¬ 
namic  mathematical  model  of  the  SIMSAT  plant  (see  Appendix  B).  Originally  used  in 
system  modeling  and  momentum  wheel  sizing,  these  equations  facilitated  control  law  de¬ 
velopment,  simulation,  and  operational  software  verification.  Based  on  the  Matlab  coding 
of  the  equations  of  motion7,  a  SIMSAT  plant  model  was  developed  within  the  Simulink 
environment.  This  plant  model  was  developed  with  the  same  assumptions  made  in  the 
equations  of  motion  development  (see  Appendix  B).  For  the  Simulink  version,  the  plant 

7 Matlab  code  is  provided  in  the  SIMSAT  User’s  Manual. 
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model  also  included  code  to  link  the  equations  of  motion  with  the  controller  in  a  realistic 
manner. 


4.5.6  Controller  Model.  Having  the  equations  of  motion  to  serve  as  a 
model  of  the  SIMS  AT  plant,  the  next  step  was  to  develop  a  controller  that  was  capable 
of  performing  three-axis  active  control.  For  this  initial  controller,  it  was  assumed  that 
sensor  noise  from  the  gyros  was  negligible  (in  addition  to  the  other  assumptions  made 
while  developing  the  equations  of  motion).  As  shown  in  Appendix  C  (Momentum  Wheel 
Sizing),  the  asymmetric  nature  of  SIMS  AT  led  to  inertial  coupling  between  the  roll,  yaw, 
and  pitch  axes.  As  a  result,  simple  open-loop  control  would  not  successfully  maintain 
SIMS  AT  stability.  Instead,  closed-loop  feedback  control  was  required. 

Figure  4.5  demonstrates  the  baseline  closed-loop  control  design.  Since  the  gyros  to 
be  used  onboard  SIMS  AT  provide  angular  velocity  signals,  rate  feedback  was  available  to 
the  controller.  In  addition,  angular  position  feedback  was  available  by  numerically  solving 
the  Euler  rate  equations. 


Explanation  of  Figure  4.5  is  as  follows: 


•  Ocom  =  user  command  input  vector  representing  desired  attitude  angles 


^2  com 
^3  com 


where 

6icom  =  desired  roll  angle 
6 2com  =  desired  yaw  angle 
03com  =  desired  pitch  angle 
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Figure  4.5  Closed-Loop  Feedback  Control 

The  user  inputs  all  desired  attitude  angles  in  degrees,  the  computer  simulation  then  con¬ 
verts  these  angles  to  radians. 

•  Ki  =  3  by  3  gain  matrix  of  real  numbers,  baselined  to  be  a  diagonal  matrix  with  off- 
diagonal  terms  equal  to  zero. 

•  K2  =  3  by  3  gain  matrix  of  real  numbers,  baselined  to  be  a  diagonal  matrix  with  off- 
diagonal  terms  equal  to  zero. 

•  K4  =  3  by  3  gain  matrix  of  real  numbers,  baselined  to  be  a  diagonal  matrix  with  off- 
diagonal  terms  equal  to  zero. 

•  & sat  com  =  user  command  input  vector  representing  desired  SIMS  AT  rotation  rates 
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& SAT  com  ~ 


desired  roll  rate 
desired  yaw  rate 
desired  pitch  rate 

The  user  inputs  these  rates  in  degrees/second,  the  computer  simulation  then  converts  these 
to  radians/second. 

Note:  wsATcom  does  not  represent  desired  Euler  rates  (defined  as  the  time  derivatives  of  the 
roll,  yaw,  and  pitch  angles).  Instead,  this  vector  represents  the  desired  angular  velocity  of 
SIMS  AT,  written  in  the  ‘b5  basis  set  (body-fixed  reference  frame),  with  respect  to  inertial 
space. 

•  ‘-1’  block  =  scaling  factor,  needed  because  SIMS  AT  reacts  (ideally)  in  the  opposite  direc¬ 
tion  from  a  commanded  torque  (according  to  the  law  of  conservation  of  angular  momentum 
for  a  rigid  body). 

•  djyjhicom  —  feedback  control  vector  of  commanded  momentum  wheel/motor  speeds  (in 
radians/second),  calculated  from  block  diagram  algebra 


hi  com  ~ 


wheel  1  commanded  speed 
wheel  2  commanded  speed 
wheel  3  commanded  speed 


Motor  speed,  rather  than  motor  torque,  was  chosen  as  a  control  input  because  the  Ani- 
matics  BL-3450  motor  was  designed  only  for  speed  control.  As  a  result,  motor  torque  is 
indirectly  controlled  via  motor  speed. 

Note:  The  Animatics  motor  speed  controller  (amplifier)  is  a  separate  item  from  the  motor. 
•  tiyjhiucom  =  user  command  input  vector  of  desired  wheel  speeds 


^whlucom  — 


wheel  1  desired  speed 
wheel  2  desired  speed 
wheel  3  desired  speed 
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The  user  inputs  these  desired  wheel  speeds  in  RPM,  the  computer  simulation  then  converts 
these  to  radians/second. 

•  lwhl  =  moment  of  inertia  of  the  wheel  about  an  axis  passing  through  its  axle.  This  scalar 
quantity  is  the  same  for  all  three  wheels  since  the  wheels  are  identical  in  mass  and  shape. 
I whl  was  calculated  from  the  final  momentum  wheel  design  (i.e.,  the  8.625”  outer  diameter 
momentum  wheels  being  produced  by  the  AFIT  fabrication  shop)  as: 

lwhl  =  -0195  kg-m2 

•  K3  =  simple  scalar  gain  representing  the  motor  (and  amplifier)  transfer  function.  This 
gain  roughly  approximates  the  motor  dynamics  necessary  for  converting  a  wheel  speed 
command  input  to  a  torque  output.  Since  Animatics  considered  its  motor  and  amplifier 
transfer  function  as  “proprietary”  information,  a  scalar  gain  was  used  to  expedite  SIMS  AT 
closed-loop  analysis.  Experimental  determination  of  the  motor  transfer  function  was  not 
possible  because  of  time  limitations  and  because  the  motors  had  not  been  acquired  yet. 

Determination  of  K3:  The  motor/motor  controller  subsystem  is  represented  by  the  inner¬ 
most  feedback  loop  in  Figure  4.5.  For  one  motor/motor  controller,  this  subsystem  was 
simplified  to  be  a  scalar  gain,  Kmotor,  and  an  integrator  as  shown  in  Figure  4.6. 


Figure  4.6  Motor  Closed-Loop  Feedback 
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The  closed-loop  transfer  function  of  the  motor/motor  controller  subsystem  (in  Laplace  ‘s’ 
domain)  is: 


^whl{s)  _  Kmotor 

^ivhlcom{s)  &  K motor 

where 

X  -  *L 

motor  —  T 

1whl 

Using  this  simple  transfer  function,  a  value  of  K mofor  was  sought  to  give  a  “reasonable” 
step  response  in  the  time  domain.  Prom  the  36V  Torque  vs.  Wheel  Speed  curve,  the 
midrange  speed  of  the  motor  is  approximately  135  rad/sec  (1300  RPM).  Therefore,  a  135 
rad /sec  step  command  for  u)whicom  was  used  as  the  input.  Based  on  trial  runs  with  the 
SmartMotor,  it  was  known  that  the  motor  (starting  from  rest)  took  two  to  three  seconds  to 
reach  its  midrange  speed  after  receiving  a  step  command.  It  was  also  know  that  overshoot 
of  a  commanded  speed  was  minimal.  With  this  in  mind,  setting  K motor  equal  to  3  gave  a 
reasonable  response  with  no  overshoot  and  approximately  two  seconds  of  settling  time. 

Note:  For  this  analysis,  it  was  assumed  the  dynamics  of  the  BL-3450  motor  were  the  same 
as  the  SmartMotor. 

Solving  for  K3  used  in  Figure  4.5: 

K3  =  Kmotor0-whl) 

K3  =  3(.0195) 

K3  =  0.0585 

•  fcom  =  feedback  control  vector  of  commanded  torques  to  each  motor  (in  Newton-meters), 
calculated  from  block  diagram  algebra 
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motor  1  commanded  torque 

Tcoml 

Tcom  " 

motor  2  commanded  torque 

= 

TCom2 

motor  3  commanded  torque 

TComS 

•  wwhi  =  vector  representing  the  measured  speed  of  each  momentum  wheel  in  rad/sec.  In 
the  real  world,  uwhi  will  be  provided  by  tachometer  signals  from  the  amplifiers. 

•  T  —  vector  of  each  motor’s  output  torque  (in  N-m) 


motor  1  output  torque 

minimum  [  \  Tcom  i , 

1 - 

3 

3 

h 

T  = 

motor  2  output  torque 

= 

minimum  [  \  Tcom  2 , 

T(u)whi2)  |] 

motor  3  output  torque 

minimum  [  |  Tcom3 , 

- 1 

co 

3 

T{u)whi )  is  calculated  from  the  36V  Torque  vs.  Wheel  Speed  curve  described  in  the  mo¬ 
mentum  wheel  sizing  problem  of  Appendix  C. 

Since  the  absolute  value  of  Tcom i,  Tcom 2,  or  Tcom 3  could  be  unrealistically  large,  the  min¬ 
imum  operator  is  needed.  This  prevents  the  computer  simulation  from  producing  motor 
output  torque  (Ti,  T2,  or  T3)  that  exceeds  the  motor’s  maximum  continuous  torque  capa¬ 
bilities. 

•  =  vector  of  each  wheel’s  angular  acceleration  in  rad/sec2 

uwhl  =  T/lwhi 

•  j  block  =  represents  integration  with  respect  to  time  (in  the  ”s”  domain). 

•  SIMS  A  T  EOM  block  =  represents  the  SIMS  AT  equations  of  motion 

•  usat  =  vector  representing  the  angular  velocity  of  SIMS  AT,  written  in  the  ‘b’  basis 
set,  with  respect  to  inertial  space.  In  the  real  world,  A  sat  would  be  measured  from  the 
onboard  gyros. 


US  ATI 

roll  rate 

As  AT  = 

USAT2 

= 

yaw  rate 

US  ATS 

pitch  rate 
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Note  again  that  the  Euler  rates  are  not  contained  in  this  vector 

•  0  —  vector  of  Euler  angles  (in  radians)  resulting  from  SIMS  AT  motion  (angles  are  later 
converted  to  degrees  for  graphing  purposes) 


01 

roll  angle 

6  = 

02 

= 

yaw  angle 

03 

pitch  angle 

As  described  in  the  equations  of  motion  development  (Appendix  B),  the  Euler  angles,  9,  are 
calculated  by  numerically  solving  the  Euler  rate  (6)  equations.  The  Euler  rate  equations 
are  written  as  a  function  of  us  at- 

•  For  computational  efficiency,  a  MATLAB  variable  time-step,  Runge-Kutta  numerical  in¬ 
tegration  routine  (‘ODE  45’)  was  used  to  solve  for  the  system  state.  The  state  vector  was 
defined  as: 


Uwh.ll 
Uwhl2 
W whl3 
Us  ATI 
&SAT2 
USATZ 

9l 

#2 

#3 


Specifically,  Runge-Kutta  integration  was  used  to  solve:  x  =  f(a?) 

4-5.7  SIMS  AT  Control  Options.  At  this  point  in  the  design  process,  the 
customers  were  interested  in  demonstrating  basic  feedback  control  of  SIMSAT ,  not  neces¬ 
sarily  optimal  control.  The  error  signals  (error  =  command  signal  -  measured  signal)  were 
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manipulated  through  simple  gain  matrices  to  demonstrate  closed-loop  control.  Although 
the  SIMS  A  T  equations  of  motion  represent  a  nonlinear  system,  basic  control  was  achieved 
by  varying  Ki,  K2  and  K4.  Detailed  linear  control  analysis  methods,  such  as  linearization 
of  the  equations  of  motion  about  certain  operating  points,  closed-loop  pole  placement,  and 
gain  scheduling,  were  not  attempted  in  this  thesis.  Since  SIMSAT  is  an  experimental  test 
bed,  other  control  approaches  can  be  evaluated  by  future  users. 

The  closed-loop  control  design  shown  in  Figure  4.5  gives  the  user  five  control  options. 
For  all  control  options,  it  is  assumed  SIMSAT  begins  at  a  “base”  configuration  at  time 
t=0.  In  the  “base”  configuration  at  t=0,  the  SIMSAT  body-fixed  axis  system  (‘bi’,  ±2’ 
and  lb35  basis  set)  described  in  Appendix  B  is  aligned  with  the  inertial  axis  system  (‘x’, 
‘y’  and  cz’  basis  set).  The  origin  of  the  inertial  axis  system  is  located  at  the  center  of  the 
central  sphere  and  the  ‘y’  inertial  axis  points  directly  at  the  laboratory  ceiling.  The  £x’ 
inertial  axis  points  at  a  pre-defined  location  in  the  laboratory,  such  as  a  painted  mark  on 
the  north  laboratory  wall  (or  any  other  convenient  wall).  With  the  ‘x’  and  ‘y’  inertial  axes 
defined,  the  V  inertial  axis  can  be  deduced  from  right-handed  orthogonality. 

All  SIMSAT  maneuvers  within  the  five  control  options  are  initiated  by  step-commands. 
Before  a  maneuver  is  initiated  (at  t=0),  the  SIMSAT  state  vector,  x ,  is  assumed  to  be  zero 
(i.e.,  3whi  =  0,  <2 sat  —  0  and  9  =  0).  For  this  thesis,  sequential  control  maneuvers  are 
not  attempted.  In  other  words,  after  one  step-command  maneuver  is  completed,  the  SIM¬ 
SAT  state  vector  is  reset  to  zero  in  the  computer  simulation  before  the  next  maneuver  is 
initiated. 

The  five  control  options  are  described  below: 

Option  1  (Target  Mode): 

The  user  enters  a  desired  roll  angle  (range  is  ±180  degrees),  desired  yaw  angle  (range  is 
±360  degrees),  and  desired  pitch  angle  (range  is  ±25  degrees).  For  Target  mode: 


Ki  = 


kroll  0  0 

0  kyaw  0 

0  0  kpitcfi 


where  krou,  kyaw  and  kpuch  are  control  design  variables. 
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krollrate 


0 


*^2  0  kyawrate  0 

0  0  &pz£c/irate 

where  kroliratei  fcyawrate  &nd  fcpitchrate  <mcq  control  design  variables. 

K3  -  .0585 

1  0  0 

k4  =  0  10 

0  0  1 

desired  roll  angle 

Scorn  —  desired  yaw  angle  (degrees) 
desired  pitch  angle 

&  SAT  com  =  0 

'  *  “4 

W whlucom  =  0 

Option  2  (Target  Mode  with  Roll  Rate): 

The  user  enters  a  desired  yaw  angle  (range  is  ±360  degrees)  and  desired  pitch  angle  (range 
is  ±25  degrees).  The  user  also  enters  a  desired  roll  rate  for  SIMS  AT  (range  is  ±9  RPM 
-  without  thrusters,  SIMS  AT  cannot  spin  outside  this  range).  The  desired  effect  of  this 
maneuver  is  for  SIMS  AT  to  point  at  a  target  while  rolling.  For  this  option: 

0  0  0 

Kx  =  o  kyaw  0  where  kyaw  and  kvitch  are  control  design  variables. 

0  0  kpitch 
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k2  = 


1  0 

0  kyawrate 

0  0 


0 

0 

kpitchrate 


where  kyawTate  and  kpitchrate  ate  control  design  variables. 


K3  =  .0585 


K4  = 


rollrate  ®  ® 

0  1  0 

0  0  1 


where  k$roarate  is  a  control  design  variable. 


dc.nm.  — 


0 

desired  yaw  angle 
desired  pitch  angle 


(degrees) 


M  SAT  com  — 


desired  roll  rate 
0 
0 


(rad/sec) 


w whlucom  —  0 


Option  3  (Roll  Spin  Mode): 

The  user  enters  a  desired  roll  rate  for  SIMS  AT  (range  is  ±9  RPM).  The  desired  effect  of 
this  maneuver  is  for  SIMS  AT  to  spin  about  the  roll  axis  while  minimizing  motion  about 
the  yaw  and  pitch  axes.  For  this  option: 


Ki 


0  0 

0  kyaw 

0  0 


0 

0 

kpitch 


where  kyaw  and  kpitch  are  control  design  variables. 
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k2  = 


1  0 

0  hyawrote 

0  0 


0 

0 

kpitchrate 


where  kyaWrate  and  kpitchrate  are  control  design  variables. 


K3  =  .0585 


K4  = 


^4 TOUTate  ^  ^ 

0  1  0 

0  0  1 


where  &4  ;irote  is  a  control  design  variable. 


@r.nm.  —  0 


^ SAT com 


desired  roll  rate 
0 
0 


(rad/sec) 


a* whlucom  —  0 


Option  4  (Yaw  Spin  Mode): 

The  user  enters  a  desired  yaw  rate  for  SIMS  AT  (range  is  ±2.6  RPM  -  without  thrusters, 
SIM  SAT  cannot  spin  outside  this  range).  The  desired  effect  of  this  maneuver  is  for  SIMS  AT 
to  spin  about  the  yaw  axis  while  minimizing  motion  about  the  roll  and  pitch  axes.  For 
this  option: 


Ki 


kroll  0 

0  0 

0  0 


0 

0 


kpitch 


where  kroa  and  kpitCh  are  control  design  variables. 
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k2  = 


faollrate  0 

0  1 


0 


0 

0 


0  fat. 


'pitchrate 


where  kTOuTate  and  kpitchrate  are  control  design  variables. 


K3  =  .0585 


K4  = 


1  0 

^  ^^yawrate 

0  0 


0 

0 

1 


where  fa  Tate  is  a  control  design  variable. 


Gcom  —  0 


w  SAT com 


0 

desired  yaw  rate 
0 


(rad/sec) 


w whlucom  — 0 

Option  5  (Wheel  RPM  Mode): 

The  user  enters  desired  speeds  for  each  of  the  momentum  wheels  (user’s  range  is  ±200 
RPM).  This  mode  will  be  rarely  used  because  it  is  an  open-loop  SIMSAT  control  method. 
Since  Euler  angle  and  body  rate  feedback  are  not  used,  direct  wheel  speed  control  will 
quickly  reveal  the  coupled  inertia  properties  of  SIMSAT.  For  this  option: 

Ki  =0 

K2  =  0 

K3  =  .0585 

K4  =  identity  matrix 

@com  =  0 
&  SAT  com  =  0 
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Wwhlucom 


desired  wheel  1  speed 
desired  wheel  2  speed 
desired  wheel  3  speed 


(rad/sec) 


4.5.8  Matlab  Simulation.  Once  the  basic  closed-loop  controller  was 
developed,  it  was  necessary  to  determine  gain  values  that  would  provide  adequate  SIMSAT 
control  for  the  five  operational  modes.  A  Matlab  simulation  of  the  closed-loop  controller 
was  used  as  part  of  an  iterative  gain-determination  process.  Since  SIMSAT  is  a  non-linear 
system,  gains  developed  for  one  maneuver  could  be  inadequate  for  a  different  operating 
regime.  Also,  within  each  of  the  five  operational  modes,  there  are  an  infinite  number  of 
possible  maneuvers.  Therefore,  a  few  nominal  maneuvers  within  each  operational  mode 
were  chosen  for  simulation  in  Matlab. 

Appendix  G  shows  possible  matrix  gain  values  and  Matlab  output  graphs  for  these 
nominal  maneuvers.  As  stated  previously,  these  maneuvers  are  NOT  performed  sequen¬ 
tially  and  the  SIMSAT  state  vector  is  set  to  zero  before  each  maneuver.  The  gain  values 
were  chosen  to  reduce  overshoot,  avoid  excessive  oscillations,  and  track  the  command  sig¬ 
nal  within  a  reasonable  amount  of  time.  However,  certain  SIMSAT  maneuvers,  such  as 
spinning  about  the  roll  axis,  are  inherently  unstable  and  control  is  difficult. 

4.5.9  SlMULINK  Model  Development.  Once  the  SIMSAT  system  dy¬ 
namics  were  understood,  as  discussed  above,  SlMULINK  was  used  to  code  the  plant  and 
controller  equations  for  use  with  the  dSPACE  system  and  onboard  AutoBox8.  The  Mat¬ 
lab  simulation  was  used  as  an  independent  verification  of  the  SlMULINK  coding  and  aided 
debugging  efforts.  Due  to  the  graphical,  block  diagram  nature  of  SlMULINK,  the  command 
and  control  process  was  broken  into  several  segments  linked  by  signal  lines  within  the 
software  code9.  The  top-level  architecture  contained  the  following  categories  of  blocks: 

8Reference  the  Simulink  User’s  Guide  [35]  for  more  detailed  Simulink  development  procedures. 

9The  “signal  lines”  simply  defined  what  variables  were  passed  from  one  block  to  another,  in  a  graphical 
manner. 
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•  Various  input  and  output  ports  (for  commanding  SIMS  AT  and  receiving  telemetry 
data  from  its  systems). 

•  The  controller  subsystem  (containing  gains  for  both  SIMS  AT  motion  and  motor 
control  feedback). 

•  The  SIMS  AT  plant  subsystem  (including  the  equations  of  motion  representing  the 
plant  in  the  off-line  simulation  code). 

•  An  Euler  transformation  segment  (to  convert  onboard  rate  gyro  measurements  to 
the  inertial  coordinate  system). 

•  Miscellaneous  blocks  (for  unit  conversions,  math  operations,  and  signal  flow). 

4-5.9. 1  General  Topics.  To  begin  coding  the  command  and  control 
software  for  SIMS  AT,  the  Simulink  model  development  application  was  started  by  either 
selecting  the  “Simulink”  or  “dSPACE  Library”  icons  in  the  dSPACE  window.  Simulink 
is  accessed  from  the  Matlab  Command  Window  by  selecting  the  “New  Simulink  Model” 
icon  on  the  toolbar,  or  typing  “simulink”  at  the  MATLAB  command  prompt. 

A  few  points  must  be  stated  in  order  to  understand  the  architecture  of  the  Simulink 
software  code.  The  ability  to  create  “masked”  blocks  within  Simulink  was  used  extensively 
to  simplify  the  top-level  code.  For  example,  the  controller  subsystem,  SIMS  AT  equations 
of  motion,  and  Euler  transformations  mentioned  above  all  appear  as  single  blocks  in  the 
top-level  architecture.  However,  with  Simulink’s  ability  to  “look  under  the  mask,”  the 
code  required  to  accomplish  the  top-level  function  can  be  accessed10.  Since  Simulink’s  pre¬ 
existing  “block  library”  only  contains  a  limited  number  of  fundamental  math  functions, 
this  capability  allows  the  user  to  create  a  new  library  with  self-developed,  application 
specific,  block  functions. 

In  the  development  of  the  SIMS  AT  code,  two  other  items  were  necessary  to  con¬ 
sider.  It  was  important  to  keep  short  the  lengths  of  names  given  to  all  components  of 
the  Simulink  code,  since  descriptive  names  of  excessive  length  caused  problems  with  the 

10 All  Simulink  code  is  provided  in  the  SIMSAT  User’s  Manual. 
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compilation  of  the  code.  Also,  although  the  capability  existed,  external  Matlab  func¬ 
tions  were  avoided  since  their  use  would  result  in  slower  processing  speeds.  This  included 
not  using  the  Simulink  “MATLAB  Fen,”  “Memory,”  or  “S-Function”  blocks  invoking  M- 
files.  In  addition  to  the  slower  speeds  resulting  from  use  of  these  blocks,  the  software  for 
download  to  AutoBox  cannot  automatically  compile  them.  These  and  other  limitations  of 
Simulink  are  outlined  in  the  Simulink  User’s  Manual.  Since  this  manual  also  provides 
descriptions  of  the  existing  Simulink  blocks,  it  is  recommended  that  future  users  have  this 
source  available  as  a  guide  while  coding  in  Simulink. 

In  general  terms,  it  was  necessary  to  develop  top-level  code  that  could  receive  com¬ 
mand  inputs  from  the  ground  station,  convert  the  input  values  into  the  appropriate  units, 
and  allow  these  values  to  be  used  by  the  controller.  In  addition,  the  controller  needed 
the  values  of  the  current  SIMS  AT  system  state,  including  position,  angular  velocity,  and 
momentum  wheel  rates.  Therefore,  the  code  had  to  provide  for  receiving  these  state  values 
from  the  SIMS  AT  plant.  Once  all  input  values  were  available,  the  controller  could  then 
determine  the  necessary  momentum  wheel  speeds  to  achieve  the  commanded  orientation. 
In  the  case  of  the  off-line  simulation,  these  wheel  speeds  were  input  into  the  SIMS  AT 
equations  of  motion  subsystem.  Based  on  the  system  dynamics,  this  block  determined  the 
resulting  SIMS  AT  angular  acceleration.  An  integrator  within  the  code  was  used  to  find 
the  angular  velocity  to  use  as  simulated  gyro  measurements.  For  real-time  applications, 
code  allowing  calculated  wheel  speeds  to  be  sent  to  hardware  components  was  required. 
The  code  also  needed  to  accept  inputs  from  the  rate  gyros  and  the  wheel  tachometers.  A 
means  for  using  Euler  angles  to  transform  gyro  data  into  the  inertial  reference  frame  was 
coded,  allowing  the  angular  data  to  be  routed  back  as  necessary  to  the  controller.  Finally, 
the  top-level  code  provided  a  means  to  output  telemetry  data  to  the  ground  station.  The 
Simulink  development  of  the  above  process  is  outlined  in  the  following  discussion. 

4.5. 9. 2  Simulink  Code  Segments. 

IO  Ports.  There  were  four  main  types  of  ports  used  within  the 
Simulink  code  for  passing  variables  in  and  out  of  the  software.  “Inports”  were  used  to 
input  user  commands  to  the  system,  while  “Outports”  were  used  to  output  telemetry  data 
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to  ground  station  displays.  A  dSPACE  DAC  port  was  used  to  interface  software  with  the 
appropriate  DSP  card  in  AutoBox,  and  a  dSPACE  ADC  port  was  used  for  bringing  data  off 
the  DSP  card  into  the  software.  The  inport/outport  blocks  were  used  since  they  provided 
interfaces  that  could  be  easily  linked  with  external  software,  such  as  that  used  on  the  ground 
station.  The  dSPACE  blocks  were  specially  designed  by  dSPACE  to  allow  for  software 
interface  with  the  AutoBox  hardware.  Since  the  inports  and  outports  were  generally  used 
to  input  or  output  a  single  variable,  it  was  necessary  to  use  “Mux”  and  “Demux”  blocks  to 
combine  single  values  into  vectors  or  separate  a  vector  into  its  components,  respectively. 
See  Figure  4.7  for  an  example  of  how  these  blocks  were  integrated  together.  All  these 
blocks  were  available  in  the  standard  Simulink  and  dSPACE  block  libraries,  so  further 
details  can  be  obtained  from  the  Simulink  User’s  Manual  and  dSPACE  documentation. 

f~  COCKPIT  IN-PORTS  | 
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Figure  4.7  Simulink  code  for  data  input  and  output 


Controller.  This  block  was  based  on  the  controller  model  as  de¬ 
veloped  in  the  discussion  above  (see  Figure  4.8).  The  controller  subsystem  contained  the 
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gains  for  both  SIMS  AT  motion  and  motor  control  feedback  and  a  block  for  comparing 
the  desired  torque  with  the  available  torque  based  on  motor  torque  curve  equation(s)  and 
maximum  wheel  speed(s).  After  determining  the  torque  command  to  supply  to  the  motors, 
this  command  was  converted  to  wheel  acceleration  and  then  integrated  to  wheel  speed. 


THIS  SUBSYSTEM  DETERMNES  THE  WHEEL  SPEED  REQUIRED 
TO  CHANGE  FROM  CURRENT  ORIENTATION  TO  OESIRED  ORENTATION 


Figure  4.8  Controller  Subsystem 

Comparison  Subsystem.  Using  Simulink  relational  operators, 
this  block  compares  the  desired  torque  to  the  available  torque  generating  capability  of 
the  motors.  The  lesser  of  the  two  is  passed  on  as  the  torque  command  to  the  system.  To 
prevent  momentum  wheel  saturation,  this  block  also  compares  the  measured  wheel  speed  to 
the  maximum  wheel  speed  and  uses  the  lesser  of  the  two.  See  Figure  4.9  for  an  illustration 
of  the  Simulink  code.  In  this  way,  the  controller  represents  the  physical  capabilities  of 
the  motor-momentum  wheel  assembly. 

SIMSAT  Plant.  This  section  of  code  represented  the  dynamics  of 
how  SIMSAT  would  react  to  the  commanded  wheel  speed  by  returning  simulated  rate  gyro 
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j  TORQUE  COMPARISON  AND  WHEEL  SPEED  SATURATION  \ 


separate  torques 


Figure  4.9  Compaxison  Subsystem,  within  the  Controller 

measurements.  Within  this  section  was  the  block  containing  the  equations  based  on  the 
EOM  as  derived  in  the  above  discussion.  Just  as  the  above  EOM  were  complicated,  this 
block  also  is  complicated.  However,  it  just  contains  a  graphical  representation  of  the  same 
set  of  dynamic  equations,  simply  replacing  variables  and  operators  with  Simulink  and 
“self-developed”  (in  the  case  of  cross-products)  blocks.  This  subsystem  representing  the 
SIMS  AT  plant  was  created  for  the  off-line  simulation  code.  In  the  real-time  application 
this  section  is  simply  removed  since  the  actual  physical  SIMS  AT  system  takes  its  place. 
See  Figure  4.10  for  the  top-level  representation  of  the  SIMS  AT  plant. 

Euler  Transformation.  Although  pictured  as  a  single  block,  this 
subsystem  was  split  into  four  sections  functionally:  (1)  orientation  input,  (2)  rate  input,  (3) 
Euler  equations,  and  (4)  rate  output.  Standard  Simulink  blocks,  such  as  “Trigonometry” 
and  “Product,”  were  used  to  build  the  Euler  equations.  “Goto”  and  “From”  blocks  were 
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Figure  4.10  Top-Level  SIMS  AT  Plant  Model 

used  to  connect  input  variable  signals  to  the  necessary  equations  to  provide  a  clearer 
presentation  than  with  direct  signal  lines.11 

Unit  Conversions .  As  the  ground  station  commands  are  input  in 

degrees,  it  was  necessary  to  convert  to  radians  within  the  code.  Likewise,  the  code  converts 
from  radians  and  rad/sec  to  degrees  and  deg/sec  for  SIMS  AT  motion  data  and  rad/sec  to 
RPM  for  wheel  speed  output  to  the  ground  station  components.  These  conversions  were 
accomplished  within  the  code  by  using  the  standard  Simulink  linear  “Gain”  block. 

Signal  Flow .  For  proper  signal  flow  in  the  off-line  simulation  code, 

“Goto”  and  “From”  blocks  were  used  to  demonstrate  where  the  DSP  blocks  were  in  the 
real-time  application.  It  is  very  straightforward  to  see  what  variables  are  used  by  functions 

11  No  figures  axe  presented  for  this,  or  following,  categories  since  most  Simulink  blocks  have  already  been 
illustrated. 
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within  SlMULlNK  due  to  its  graphical  nature.  Signal  lines  connect  all  blocks,  with  arrows 
indicating  whether  a  variable  passing  over  a  line  is  an  input  or  an  output  of  a  block. 

Other.  A  built  in  “hook”  for  power  signal  monitoring  (low  voltage 
saturation)  was  placed  within  the  code.  Although  currently  not  being  used,  it  provides 
the  capability  of  using  voltage  data  within  the  code.  This  also  was  designed  to  illustrate 
an  example  for  future  experimental  signals. 

4. 5. 9. 3  Constants  and  Variables.  The  following  lists  present  the 
constants  defined  within  the  SlMULlNK  code  and  the  variables  linked  with  the  graphical 
user  interface.  (NOTE:  The  constants  are  values  that  must  be  defined  in  the  code  before 
compiling,  and  may  change  based  on  SIMSAT  configuration  modifications.  The  variables 
are  values  that  can  be  changed  real-time  during  an  experiment.  Select  the  appropriate 
block  within  the  SlMULlNK  code  to  open  the  dialog  box  for  entering  the  necessary  block 
parameters.  See  Figure  4.11  and  Figure  4.12  for  examples.) 

Control  Constants.  These  are  the  values  defined  in  the  Controller 
Subsystem  (required  for  both  simulations  and  real-time  applications). 

•  Momentum  Wheel  Inertia  (scalar  value)  -  used  within  the  controller  block  to  calculate 
momentum  wheel  acceleration  from  the  torque  command. 

•  Maximum  Wheel  Speed  (scalar  value)  -  used  within  the  comparison  block  of  the 
controller  subsystem  to  prevent  momentum  wheel  saturation. 

•  K1  Gain  Matrix  (roll,  yaw,  pitch  diagonal  elements)  -  used  within  the  controller 
subsystem  as  proportional  gain  on  SIMSAT  position  error. 

•  K2  Gain  Matrix  (roll,  yaw,  and  pitch  diagonal  elements  -  used  within  the  controller 
subsystem  as  derivative  gain  on  SIMSAT  angular  velocity. 

•  K3  Gain  (scalar  value)  -  used  within  the  controller  subsystem  for  motor- control 
feedback. 
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Figure  4.11  Controller  Gain  Parameters 

Plant  Constants.  These  constants  are  the  values  defined  in  the 
plant  subsystem  (only  required  for  simulations). 

•  Momentum  Wheel  Inertia  Matrices  (Jl,  J2,  J3)  -  both  about  wheel  center  of  mass, 
with  respect  to  wheel  reference  frame  and  about  SIMSAT  center  of  mass,  with  re¬ 
spect  to  SIMS  A  T  reference  frame;  based  on  the  current  configuration  of  the  SIMSAT 
system. 

•  Composite  SIMSAT  Inertia  Matrix  (Icomp)  -  calculated  as  previously  discussed; 
based  on  the  current  configuration  of  the  SIMS  A  T  system. 

•  Inverse  Matrix  from  Sum  of  Inertia  Matrices  [INV(I+J1+J2+J3)]  -  see  above  discus¬ 
sion  for  a  definition. 

Variables.  These  values  axe  accessed  from  the  user  interface,  and 
can  be  changed  real-time. 
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Figure  4.12  Equation  of  Motion  Parameters 


Desired  Roll  Command  -  entered  as  degrees  of  desired  roll  using  the  graphical  inter¬ 
face;  converted  to  radians  within  the  Simulink  code. 

Desired  Yaw  Command  -  same  as  roll  command. 

Desired  Pitch  Command  -  same  as  roll  and  yaw  command. 

(Pitch  Angle  Limit)  -  to  prevent  commanding  the  system  to  a  pitch  angle  beyond 
the  system’s  physical  limits;  although  not  capable  of  preventing  the  system  from 
attempting  an  impossible  pitch  angle  due  to  coupling  with  roll  and  yaw,  this  prevents 
the  ground  operator  from  intentionally  entering  an  unattainable  pitch  angle.  (This 
was  not  a  true  variable  used  within  the  Simulink  code,  but  a  limitation  on  the 
range  of  user  interface  controls.  Therefore,  the  ground  station  instruments  can  also 
be  changed  to  reflect  a  “margin”  for  commanded  pitch  angle.) 


4-5. 9. 4  Testing.  The  following  steps  were  completed  to  test  the  control 
law  software  by  running  an  off-line  simulation.  As  an  aid  in  debugging,  there  are  a  few  tools 
available  within  the  SlMULINK  environment.  Under  “Format”  on  the  toolbar,  the  user  has 
options  for  the  display  of  signal  lines.  By  selecting  “Wide  Vector  Lengths”  the  thickness 
of  signal  lines  reflects  the  number  of  elements  passing  over  it.  For  a  scalar  variable,  the 
line  width  will  remain  the  same.  However,  for  vector  variables,  the  line  widths  will  become 
bold.  Selecting  “Line  Widths”  will  display  the  exact  number  of  values  entering  or  leaving  a 
block  over  an  individual  signal  line.  These  options  can  be  selected  before,  during,  or  after 
running  a  simulation,  but  results  will  not  appear  before  a  simulation  has  been  started. 

•  Start  the  SlMULINK  model  development  application  by  either  selecting  the  icon  in 
the  dSPACE  window,  opening  Matlab  and  selecting  the  “New  SlMULINK  Model” 
icon  on  the  toolbar,  or  typing  “simulink”  at  the  MATLAB  command  prompt. 

•  Open  the  desired  SIMS  AT  model  file  (i.e.  “SSMtest.mdl” )  from  the  appropriate 
directory. 

•  In  the  “Simulation,  Parameters...”  menu,  make  sure  the  desired  solver  options  are 
selected.  Although  a  fixed-step  solver  is  necessary  for  real-time  applications,  the  type 
of  solver  can  be  varied  during  off-line  testing.  (A  fixed-step  solver  is  not  recommended 
for  initial  off-line  testing,  using  only  the  PC,  due  to  the  extremely  slow  running 
speed.) 

•  Select  “Start”  from  the  “Simulation”  menu,  or  click  on  the  “play”  icon,  to  begin 
running  the  model  within  the  Simulink  environment.  If  the  model  has  been  properly 
coded  according  to  Simulink  syntax  rules,  the  time  count  will  begin  updating  in  the 
lower  right  of  the  screen  to  signify  a  running  simulation. 

•  If  errors  exist  in  the  code,  use  the  displayed  error  messages  and  the  user’s  manual 
to  fix  the  problem (s).  One  of  the  most  common  problems  involved  incorrect  signal 
widths,  as  when  a  block  expected  a  scalar  rather  than  a  vector  input,  or  vice  versa. 
The  debugging  tools  mentioned  above  helped  in  locating  the  source  of  this  error. 
Other  errors  were  caused  by  using  incorrect  SlMULINK  blocks  to  perform  certain 
functions.  For  example,  although  the  Simulink  “Product”  block  is  “vectorized”  to 
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accept  and  return  vectors,  it  does  not  perform  a  cross-product  operation.  Therefore, 
it  was  necessary  to  develop  a  new  Simulink  block,  by  combining  existing  ones,  to 
conduct  cross-product  operations. 

•  Once  the  coding  errors  had  been  debugged  within  Simulink,  the  software  was  ready 
to  be  integrated  with  dSPACE,  as  will  be  covered  in  a  later  section. 

4.5. 9. 5  Summary.  The  following  Simulink  code  was  developed  during 
the  Detailed  Design  phase,  and  is  currently  available  for  use  with  SIMSAT. 

•  SIMSAT  model  block  library  (SSMlib.mdl):  This  is  a  file  containing  several  of  the 
Simulink  blocks  developed  for  use  in  the  SIMSAT  command  and  control  software. 
The  current  version  lists  blocks  with  the  dates  they  were  last  updated/modified. 
Besides  providing  a  back  up  of  essential  components,  it  also  allows  future  users  to 
choose  individual  blocks  from  this  library  for  use  in  new  code,  rather  than  breaking 
apart  existing  SIMSAT  code. 

•  Test  version  (SSMtest.mdl):  This  code  was  used  to  conduct  simulations  of  SIMSAT 
for  testing  the  control  laws,  command  and  display  capabilities,  and  integration  with 
dSPACE.  It  has  undergone  all  the  testing  and  compiling  described  in  this  section. 

•  Real-time  application  (SSMreal.mdl):  As  yet  untested,  this  code  is  the  same  as  the 
test  version  except  for  the  modifications  required  for  hardware-in-the-loop  applica¬ 
tions.  The  blocks  closing  the  loop  in  the  test  version  were  replaced  by  the  dSPACE 
blocks  designed  to  interface  with  the  DSP  cards  in  the  onboard  AutoBox.  In  addi¬ 
tion,  the  subsystems  used  in  the  test  version  to  simulate  the  physical  SIMS  A  T  system 
were  removed  (i.e.  the  equations  of  motion  block). 

Naturally,  future  coding  changes  will  be  necessary  based  on  the  characteristics  of  an 
experiment.  The  two  main  categories  of  coding  alterations  are  additions  to  and  modifica¬ 
tions  of  the  existing  code.  Any  experiment  added  to  the  baseline  SIMSAT  will  change  the 
inertia  of  the  system,  requiring  that  the  user  enter  the  new  inertia  values  in  the  Equations 
of  Motion  subsystem  of  the  test  version.  The  user  can  then  use  this  code  to  generate 
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any  necessary  changes  to  the  feedback  gains  for  proper  control.  These  new  values  should 
then  be  entered  into  the  real-time  application  version  of  the  software.  Finally,  any  new 
Simulink  blocks  required  for  experimental  use  should  be  added  and  tested  with  the  test 
version  before  adding  to  the  real-time  version.  Modification  of  the  existing  code  may  be  as 
simple  as  changing  the  inputs  or  outputs  and  removing  unneeded  blocks,  or  complex  such 
as  making  major  changes  to  the  feedback  control  laws. 

One  future  addition/modification  already  identified  is  the  need  for  the  software  to 
simulate,  and  provide  real-time  control  of,  gas  thrusters  used  for  momentum  dumping  to 
avoid  wheel  saturation.  Better  off-line  simulations  could  be  accomplished  by  designing 
code  to  model  sensor  noise  and  disturbance  torques.  Another  recommendation  for  possible 
future  software  revision  is  to  develop  a  method  for  recognizing  loss  of  signal  with  the 
ground  station  or  motion  instability  and  returning  the  system  to  a  stable  zero  orientation. 
However,  this  would  only  work  for  a  few  emergency  cases,  not  incidents  such  as  loss  of 
power,  onboard  computer  problem,  hardware  failure,  an  already  unstable  system,  etc.,  so 
an  emergency  “catch-all”  safety  system  will  always  be  required.  This  reality  limited  the 
usefulness  of  extensive  time  creating  “emergency”  code  during  early  software  development. 
Finally,  adding  a  “power-off”  capability  to  the  code  would  be  useful  for  sending  a  simple 
switch  command  to  power  down  the  batteries  at  the  end  of  an  experiment. 

Before  the  developed  Simulink  code  could  be  used  for  on-line/real-time  operations, 
it  had  to  be  integrated  with  the  dSPACE  software.  The  next  section  outlines  the  process 
required  to  do  this. 

4 .5. 10  dSPACE  Integration.  In  general,  to  integrate  the  code  discussed 
above  with  dSPACE  for  compiling  and  downloading  to  AutoBox,  the  following  steps  were 
taken.  (See  Appendix  H  for  detailed  information.) 

•  Power  up  the  AutoBox  and  ensure  it  is  connected  with  the  PC. 

•  Select  “dSPACE  Library”  from  the  “dSPACE  Files”  window,  or  type  “rtilib”  within 

the  MatlAB  Command  Window. 


4-51 


•  From  within  SlMULlNK,  select  “RTW  Build”  from  the  “Tools”  menu,  or  press  (Ctrl+B), 
to  begin  the  compilation  process  (if  the  RTW  Options  have  already  been  set  correctly: 
dSPACE  requires  a  fixed-step  solver  for  real-time  applications,  a  fixed  step  size  of 
0.001,  using  ode4  or  ode5,  is  recommended). 

•  The  Real  Time  Workshop  (RTW)  and  Real  Time  Interface  (RTI)  will  then  compile 
the  SlMULlNK  model  into  C-code,  generate  the  associated  files,  start  the  DSP  onboard 
AutoBox,  and  download  the  program  to  AutoBox. 

•  The  application  program  would  now  be  running  onboard  AutoBox,  until  the  DSP  is 
manually  reset  or  a  loss  of  power  occurs. 

•  With  a  successful  download,  the  previous  process  is  not  repeated  to  reload  the  com¬ 
piled  model  after  a  DSP  reset  or  power-down.  Instead,  after  restarting  AutoBox  use 
the  dSPACE  MON40NET  program  to  load  the  object  module  of  the  desired  control 
software  and  restart  the  DSP. 

4-5.11  User  Interface  Issues.  At  this  stage,  the  software  architecture 
included  the  user-created  Simulink  code  and  all  the  files  created  by  the  dSPACE  software 
during  compilation  and  download  to  the  AutoBox.  The  next  challenge  was  to  integrate 
this  onboard  command  and  control  software  with  the  user  interface  software  on  the  ground 
station  computers. 

To  meet  the  user  requirements  for  an  easy-to-use  interface  providing  command  con¬ 
trol  and  telemetry  monitoring  functions  to  an  experimenter,  the  ground  station  was  devel¬ 
oped.  This  involved  the  following  design  issues. 

•  The  ground  station  was  required  to  provide  real-time  command  and  control  of  SIM- 
SAT  operations. 

•  To  aid  in  providing  the  real-time  command  and  control,  real-time  display  of  data  dur¬ 
ing  SIMS  AT  operations,  with  control  feedback  matching  the  actual  system  behavior, 
was  necessary. 
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•  A  means  for  saving  experimental  data  (and  system  motion  data)  for  post-test  analysis 
was  required. 

•  User  controls  and  displays  should  be  easy-to-use  and  understand. 

•  Robust  user  interface  software  allowing  simple  modification  based  on  future  experi¬ 
mental  use. 

The  development  of  the  ground  station  software  is  described  in  the  next  section, 
while  the  hardware  architecture  of  the  ground  station  is  discussed  in  Section  4.5.13. 

4-5.12  Control  Law /User  Interface  Software  Integration.  The 
following  descriptions  explain  how  the  SlMULlNK-developed  command  and  control  code 
was  linked  with  the  Trace,  Cockpit,  and  RealMotion  applications12.  These  tools 
were  part  of  the  graphical  user  interface  software  provided  with  the  dSPACE  system. 
They  were  designed  to  easily  link  with  code  developed  in  Simulink  and  compiled  with 
RTW/RTI13.  Using  a  wireless  communication  link,  the  user  interface  software  running  on 
the  ground  station  computer  can  connect  with  the  simulation  software  on  the  AutoBox, 
passing  command  and  telemetry  variables  back  and  forth. 

4.5.12.1  Trace  Telemetry  Display.  This  plotting  tool  presents  time 
histories  of  variables  in  the  command  and  control  software.  The  interval  length  of  real-time 
data  capture  can  be  varied,  allowing  the  user  to  view  instantaneous  variable  updates,  or 
a  plot  covering  several  seconds,  such  as  5,  10,  or  30  seconds.  These  time  history  plots  can 
be  saved  to  a  file  following  an  experiment,  allowing  post-test  analysis  as  required.  After 
creating  a  properly  working  SIMULINK  model,  and  successfully  compiling  and  downloading 
it  to  the  AutoBox,  the  following  steps  outline  how  the  command  and  control  code  was 
linked  with  the  Trace  tool.  (See  Appendix  I  for  detailed  information.) 

12 Reference  the  Trace  [17],  Cockpit  [16],  and  RealMotion  [15]  User’s  Guides  for  detailed  description 
of  the  information  presented  in  this  section. 

13  Reference  the  RTW  [37],  RTI  [18],  and  MATLAB  Target  Language  Compiler  [36]  User’s  Guides  for 
detailed  description  of  the  information  presented  in  this  section. 
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•  The  TRACE  development  environment  consists  of  two  windows,  the  “Trace  Net  Con¬ 
trol  Panel”  and  “Trace  Plots.”  The  Control  Panel  was  used  for  the  general  process 
of  linking  a  real-time  application  with  Trace,  while  the  plotting  window  was  where 
the  graphs  for  signal  plotting  were  developed. 

•  The  initial  step  in  the  linking  process  was  to  load  the  Trace  file  created  during  the 
RTW/RTW  compilation  process.  Once  loaded,  this  file  provided  a  tree  structure  of 
the  simulation  program. 

•  Signals  desired  for  plotting  were  selected  from  a  variable  list  generated  from  the  tree 
structure. 

•  After  using  the  tree  structure  and  variable  list  to  establish  the  graphs  for  signal 
plotting,  the  Trace  “Template”  was  designed.  Plotting  options  available  included 
using  grids  on  the  graphs  and  scaling  of  axes. 

•  Of  considerable  utility  was  the  “Reference...”  option,  which  allowed  the  plotting  of 
multiple  signals  on  a  single  graph  based  on  a  reference  signal  selection.  This  capability 
was  useful  for  direct  comparison  of  related  signals,  such  as  the  roll,  yaw,  and  pitch 
angle  variables. 

•  It  was  also  determined  that  Trace  plot  data  can  be  saved  to  a  Matlab  *.mat 
file  following  a  simulation,  and  later  used  to  graph  the  results  of  the  experiment  in 
Matlab. 


4-5.12.2  Cockpit  Command  and  Control  Suite.  This  software  tool 
provided  input  control  and  output  display  instruments  that  can  be  linked  with  variables  in 
the  command  and  control  code.  Cockpit  was  designed  to  provide  real-time  command  and 
control  of  SIMSAT  operations  with  graphical  user  controls  and  displays.  The  robustness 
of  this  user  interface  software  allows  simple  modifications  for  future  experimental  use. 

The  design  of  the  Cockpit  user  interface  was  accomplished  in  a  similar  manner  to 
the  Trace  development.  Once  again,  the  appropriate  Trace  file  was  loaded,  providing 
the  same  tree  structure  and  variable  list.  Various  Cockpit  control  and  display  instruments 
were  linked  with  variables  to  provide  user  control.  Control  parameters  such  as  initial  input 
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values  and  ranges  were  set,  and  the  control  panel  design  was  saved  for  use  in  simulations 
and  real-time  applications.  (See  Appendix  I  for  more  information.)  The  following  list 
describes  the  control  instruments  planned  for  the  SIMS  AT  user  interface. 

•  Slider.  This  instrument  is  a  simple  slide  bar  that  can  be  used  for  basic  roll,  yaw,  or 
pitch  control.  Although  not  very  accurate,  it  provides  a  straightforward  control  for 
demonstration  of  general  motion. 

•  Knob.  An  alternative  for  basic  roll,  yaw,  or  pitch  control,  this  dial-like  instrument 
would  serve  the  same  function  as  the  slider.  Just  like  the  slider,  it  is  also  ineffective 
for  precise  motion  control  since  a  reasonably  sized  instrument  does  not  provide  for 
fine  command  inputs. 

•  Incremental  Input.  This  instrument  can  be  used  for  fine  roll,  yaw,  or  pitch  control  by 
allowing  incremental  commands  above  or  below  a  set  point.  For  example,  use  of  the 
slider  control  can  get  the  commanded  angle  near  the  desired  one,  and  the  incremental 
input  control  can  move  it  closer.  (The  value  of  the  increment  is  user-defined.) 

•  Numeric  Input.  This  input  provides  for  keyboard  entry  of  the  exact  roll,  yaw,  or 
pitch  commands. 

•  Pushbutton.  This  plain  button  can  be  used  to  command  roll,  yaw,  or  pitch  to  a 
pre-defined  angle.  For  example,  this  is  useful  as  a  quick  “return  to  zero”  command. 

•  Display.  Several  digital-style  numeric  displays  are  used  to  indicate  the  current  values 
of  motion  variables. 

•  Gauge.  This  instrument  is  used  for  output  display  of  SIMS  AT  angular  velocities  and 
momentum  wheel  speeds.  It  is  an  intuitive  display  since  the  pointer  can  indicate  the 
direction,  as  well  as  the  rate,  of  the  motion. 

•  Alert.  This  instrument  only  provides  a  visual  and  audible  indication  of  the  pitch 
angle  reaching  pre-set  limits.  (If  power  monitoring  is  included  in  a  future  design,  an 
“alert”  instrument  can  be  used  to  indicate  a  low  power  level.) 

•  Bar.  This  instrument  could  be  used  for  power  monitoring  by  presenting  the  current 
power  level. 
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•  On/Off  Button.  This  button  may  be  designed  to  shut  down  SIMS  AT  power.  Since 
the  command  and  control  software  must  be  running  on  the  AutoBox  before  the 
COCKPIT  user  interface  can  be  started,  this  option  only  works  for  powering  down 
after  an  experiment  (or  when  appropriate  in  an  emergency  situation),  not  for  turning 
SIMSAT  on. 

4-5.12.3  RealMotion  3-D  Animated  Display.  This  software  tool 
links  a  3-D  geometric  model  to  orientation  variable  outputs,  providing  a  real-time  3-D 
representation  of  SIMSAT  motion.  The  following  topics  cover  the  design  of  the  Real- 
Motion  application. 

A  geometric  model  (an  AutoCAD  *.dxf  file)  and  a  scene  control  file  (*.ctl)  were  cre¬ 
ated,  and  they  defined  different  “members”  of  a  baseline  SIMSAT  representation.  This 
allowed  for  naming,  coloring,  and  motion  scaling  of  individual  parts  of  the  model.  For  ex¬ 
ample,  this  capability  would  allow  a  future  experiment  incorporating  attached  appendages 
(i.e.  solar  panels)  to  emphasize  the  motion  of  the  payload  over  that  of  the  support  struc¬ 
ture.  Also,  several  observer  points-of-view  can  be  defined  within  the  scene  control  file,  as 
desired.  Once  the  geometric  model  had  been  linked  with  a  scene  control  file,  the  following 
animation  options  were  available. 

•  Off-line  simulation  with  the  use  of  a  motion  data  file  (*.mdf). 

•  On-line  simulation  when  the  simulation  program  is  running  on  a  DSP  board. 

•  Real-time  animation  when  the  command  and  control  program  is  running  on  the 
onboard  AutoBox,  and  motion  data  is  being  updated  constantly.  However,  this 
option  required  additions  to  the  software  code,  as  described  below. 

The  simulation’s  *.usr  file,  a  part  of  the  command  and  control  software  created  during 
the  dSPACE  compilation  process,  was  modified  to  create  links  between  the  SIMSAT  C- 
code  motion  variables  and  the  members  of  the  RealMotion  model.  If  the  names  of  the 
output  motion  variables  are  not  changed  within  the  original  code,  and  the  geometric  model 
is  kept  the  same,  no  further  changes  to  any  RealMotion  related  files  is  required  with 
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future  revisions.  However,  if  the  code  is  modified  by  changing  the  names  or  adding  new 
output  variables,  the  *.ctl  and  *.usr  files  will  also  need  modification.  The  *.ctl  file  must 
also  be  updated  to  reflect  any  additions  to  the  geometric  model.  (See  Appendix  J  for  more 
detail  on  creating  and  modifying  the  files  linked  to  RealMotion.) 

Upon  opening  RealMotion,  two  windows  will  appear.  The  “Status  Window”  pro¬ 
vides  background  details  based  on  a  loaded  simulation  program,  scene  control  file,  and 
geometric  model.  The  RealMotion  Display  Window  portrays  the  3-D  representation  of 
the  model.  The  status  window  is  for  reference  only,  all  RealMotion  manipulation  must 
be  done  from  the  display  window.  The  following  are  a  few  options  regarding  the  display 
window  set-up. 

•  Use  “Load  Scene...”  under  the  “File”  menu  to  open  an  existing  scene  control  file. 
If  the  associated  application  program  is  not  running  on  the  DSP  board,  an  error 
message  will  appear.  This  message  can  be  ignored  for  off-line  work. 

•  Most  scene  options  can  be  changed  from  the  default  cases  defined  by  “keywords”  in 
the  *.ctl  file  by  using  the  display  window  menus.  Keyword/menu  selections  allow 
the  specification  of  the  observer  point-of-view,  attributes  of  the  model  members,  and 
qualities  of  the  scene  such  as  lighting  conditions,  background  color,  window  size,  etc. 
(It  is  suggested  that  the  model  be  viewed  in  the  large  window.) 

•  The  “Position  Control  Tools”  toolbar  (accessed  from  the  “View”  menu)  allows  trans¬ 
lation  and  rotation  of  the  model  to  demonstrate  motion  in  off-line  status. 

•  The  “Light  Tools”  toolbar  (accessed  from  the  “View”  menu)  enables  simple  point- 
and-click  control  of  the  object  lighting.  Using  Lights  3  and  8  is  recommended  for  the 
best  visibility  of  the  model. 

With  a  simulation  running  on  the  PC’s  DSP  card,  or  the  real-time  application  running 
on  the  AutoBox,  the  geometric  model’s  orientation  will  update  based  on  the  current  motion 
variables  received  from  SIMS  AT. 

4-5.13  Ground  Station  Hardware  Architecture.  The  ground  station 
consisted  of  two  computers,  each  with  its  own  monitor  and  capability  for  wireless  commu- 
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nication  with  SIMS  AT.  The  physical  arrangement  was  based  on  the  design  conclusions  of 
Mr.  Hanke’s  thesis,  but  just  as  the  rest  of  the  system  it  is  flexible  to  allow  future  recon¬ 
figuration.  After  completing  the  initial  software  development  using  the  existing  systems, 
the  following  recommendations  for  future  ground  station  development  were  made. 

•  Reconfiguring  the  lab  arrangement  (i.e.  computer  locations)  is  recommended  to  avoid 
the  hazards  of  sitting  too  near  an  operational  SIMS  AT  during  an  experiment.  Also, 
the  operator  should  face  SIMS  AT,  so  repositioning  the  computers  farther  from  SIM- 
SAT  and  giving  the  operator  a  clear  line  of  view  will  aid  the  individual  in  matching 
ground  displays  with  actual  motion.  This  view  will  be  especially  important  during 
initial  test  runs  to  determine  if  the  controller  works  for  the  physical  system  as  well 
as  its  software  simulation. 

•  A  better  command  and  control  station  is  possible  with  alternate  computer  compo¬ 
nents.  Utilizing  two  screens  with  the  ground  control  PC  would  allow  the  user  to 
observe  real-time  updates  of  Trace  motion  plotting  on  one  screen,  while  operat¬ 
ing  the  Cockpit  instrument  panel  on  the  other.  This  arrangement  would  provide 
greater  control  to  the  experimenter  since  switching  between  displays  on  a  single  mon¬ 
itor  would  not  be  necessary.  Along  the  same  lines,  larger  monitors  would  allow  better 
display  fidelity  and  easier  access  to  more  control  instruments. 

4-5.14  User  Interface  Summary.  This  section  serves  to  encapsulate 
the  design  and  development  of  the  SIMS  AT  command  and  control  software  and  ground 
station  described  above. 

•  Dynamic  Models  of  Equations  of  Motion  and  Controller.  The  software  architecture 
used  in  command  and  control  and  user  interface  development  was  based  on  the 
mathematical  model  created  to  represent  the  SIMS  AT  system.  The  controller  design 
used  within  the  software  was  developed  and  tested  against  these  equations  of  motion, 
using  closed-loop  feedback. 

•  MATLAB.  The  Matlab  coding  environment  was  used  extensively  to  develop  the 
software  architecture.  The  equations  of  motion  and  controller  were  separately  coded 
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in  Matlab  to  provide  independent  verification  of  the  Simulink  application  software. 
Matlab  also  served  as  an  integral  part  of  the  final  software  architecture  since  it  is 
the  foundation  of  Simulink,  and  the  Trace  application  is  designed  to  save  plot  data 
into  *.mat  files  for  later  analysis  using  Matlab. 

•  SIMULINK.  This  software  served  as  the  fundamental  coding  environment.  Along 
with  dSPACE  compatibility,  Simulink  allowed  easier  software  integration  of  the 
SIMS  AT  system,  controller,  and  ground  station. 

•  dSPACE  Library.  As  an  essential  part  of  the  dSPACE  software  suite,  this  library 
provided  the  Simulink  code  blocks  for  linking  the  software  architecture  with  the 
AutoBox  hardware. 

•  RTW/RTI.  The  Real  Time  Workshop  and  Real  Time  Interface  applications  were 
used  to  convert  the  graphical  Simulink  code  into  C-code,  which  was  then  compiled 
and  downloaded  to  the  AutoBox.  They  provided  the  link  between  a  user-friendly 
coding  environment  and  the  AutoBox  compatible  code. 

•  TRA  CE.  This  application  provided  a  real-time  display  for  the  time  histories  of  motion 
variables.  It  also  supplied  the  capability  of  saving  test  results  to  a  *.mat  file,  for  later 
analysis  using  Matlab.  The  software  development  included  the  design  of  a  template 
for  the  graphs  of  variable  plots  (SSMtrace.tpl)  and  a  general  experiment  set-up  file 
(SSM-trace.exp)  used  to  define  sample  rate,  plotting  interval,  and  the  file  used  to 
link  Trace  with  the  AutoBox. 

•  COCKPIT.  User-friendly  ground  control  capabilities  were  developed  using  the  Cock¬ 
pit  application.  The  design  included  instruments  such  as  simulated  slide  bars  and 
buttons  to  send  commands  to  SIMS  AT,  and  gauges  and  numeric  displays  to  provide 
instant  feedback  on  the  measured  orientations  and  velocities.  The  graphical  user- 
interface  (Grnd-Ctrl.ccs)  was  designed  for  use  with  the  existing  system  and  ground 
station  set-up,  but  its  integration  with  the  rest  of  the  dSPACE  software  only  requires 
simple  modifications  to  meet  future  needs. 

•  RealMotion.  3-D  animation  of  real-time  SIMS  AT  motion  is  provided  by  Real- 
Motion.  Developing  this  capability  required  the  design  of  a  geometric  model  to 
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represent  SIMSAT  and  creating  or  modifying  software  code  to  provide  the  necessary 
links  between  programs.  The  geometric  model  (Simsat.dxf)  was  created  in  AutoCAD 
and  defined  for  RealMotion  use  in  the  scene  control  file  (Simsat.ctl).  Finally,  C- 
code  modifications  made  to  the  *.usr  file  created  during  compilation  of  the  original 
SlMULINK  code  linked  the  orientation  variables  to  the  RealMotion  model. 

•  Ground  Station  Configuration.  The  arrangement  of  ground  station  computers  during 
the  software  development  process  consisted  of  one  PC  with  Trace  and  Cockpit,  to 
be  used  later  as  the  “mission  operations”  and  ground  control  station,  and  another  PC 
with  RealMotion,  for  display  of  the  3-D  animation,  both  simulated  and  real-time. 
These  two  PCs  were  located  near  the  air-bearing  pedestal  in  the  lab.  Having  the 
two  PCs  co-located  during  the  detailed  design  phase  was  useful,  and  safety  concerns 
were  not  significant.  However,  it  is  recommended  that  the  current  ground  station 
configuration  be  altered  for  the  final  operational  design  to  prevent  safety  hazards  due 
to  close  proximity  to  SIMSAT. 

4-6  Structural  Design 

4 '6.1  Problem  Statement.  Structural  design  addressed  the  development 
of  a  mounting  framework  for  attaching  SIMSAT  components  to  the  central  air-bearing 
assembly.  The  structural  design  problem  was  summarized  as  follows: 

Using  the  selected  components,  design  a  structure  which  supports  easy  integration  of 
these  items  onto  SIMSAT,  maximizes  modularity,  and  minimizes  mass  and  inertia. 

4-6.2  Problem  Scope.  During  the  Concept  Exploration  and  Definition 
phase,  structural  design  began  with  general  considerations  of  the  classes  of  structural  solu¬ 
tions  deemed  most  likely  for  final  implementation.  Without  knowledge  of  the  masses  and 
volumes  of  individual  components,  however,  these  efforts  yielded  few  tangible  results.  Dur¬ 
ing  the  Preliminary  Design  phase,  however,  subsystem  decisions  were  made  which,  allowed 
for  the  overall  structural  design  to  begin.  Several  structural  alternatives  were  considered; 
but  without  specified  subsystem  components,  detailed  structural  design  was  delayed  until 
after  the  first  iteration  of  the  Detailed  Design  phase.  Once  subsystem  classes  were  nar- 
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rowed,  development  of  a  logical  support  structure  to  enhance  the  overall  performance  of 
SIMS  AT  was  initiated  in  detail.  At  this  stage,  only  the  baseline  structural  design  was 
considered;  detailed  mounting  of  components,  static  and  dynamic  responses,  and  detailed 
structural  specifications  were  investigated  in  later  design.  The  structural  design  problem 
demonstrated  the  importance  of  systems  integration  to  the  SIMS  AT  design  team,  as  the 
final  design  became  more  than  just  the  sum  of  the  characteristics  of  the  individual  parts. 

4-6.3  Structural  Issues.  The  following  issues  were  identified  as  critical  in 
the  development  of  the  baseline  structural  design: 

•  Develop  a  preferred  SIMS  AT  configuration,  to  include  relative  arrangement  of  sub¬ 
systems  and  structural  members. 

•  Ensure  the  structural  design  is  robust  and  modular  to  support  subsystem  reconfigu¬ 
ration. 

•  Incorporate  a  payload  structural  interface,  to  include  adequate  mass  and  volume 
margins. 

•  Allow  3-D  visualization  of  the  structure  prior  to  fabrication  to  aid  decision-making 
and  ensure  feasibility. 

•  As  much  as  possible,  minimize  the  mass  and  inertia  penalties  associated  with  the 
structural  design. 

4-6.4  Computer-Aided  Design  (CAD)  Software.  Nominal  position 
vectors  for  the  components  used  in  the  original  Matlab  simulation  were  estimated  from 
preliminary  SIMS  AT  hand  sketches.  Although  this  approach  provided  a  starting  point 
for  momentum  wheel  sizing,  it  was  apparent  that  computer-aided  design  (CAD)  would 
be  needed.  A  CAD  package  would  allow  exploration  of  multiple  SIMS  AT  configurations 
within  the  time  constraints  of  the  project.  Therefore,  the  team  actively  pursued  the  pur¬ 
chase  of  a  PC-based  CAD  system  to  support  structural  development.  AutoCAD  software 
(release  14),  produced  by  Autodesk,  Inc.,  was  selected  by  the  design  team  as  the  pri¬ 
mary  CAD  package  of  the  SIMS  AT  project.  Additionally,  3D  Studio  VIZ  (release  2),  also 
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produced  by  Autodesk,  Inc.,  was  used  for  three-dimensional  solid  object  visualization.  Au¬ 
toCAD  software  is  an  industry  standard,  and  it  produces  drawing  files  compatible  with 
the  dSPACE  RealMotion  display  system.  These  two  software  packages,  designed  to  be 
used  together  in  concert,  provided  a  powerful  tool  for  on-screen  manipulation  of  struc¬ 
tural  elements.  Without  these  software  packages,  the  SIMS  AT  design  effort  would  have 
been  impossible  to  achieve  on  schedule.  Additionally,  as  the  structural  design  continued 
to  mature,  cardboard  mockups  were  constructed  to  verify  computer  drawings  and  provide 
a  hands-on  environment  for  making  design  decisions.  Mockups  also  enhanced  the  ability 
of  fabrication  shop  personnel  to  visualize  the  design  and  make  valuable  suggestions. 

4-6.5  Initial  Sizing.  The  generic  Matlab  simulation  used  for  momentum 
wheel  sizing  (reference  Appendix  C)  provided  a  useful  tool  to  begin  formal  structural  design 
work.  Although  this  simulation  neglected  structural  mass,  the  simulation  demonstrated 
the  effect  of  component  weights  and  positions  on  SIMS  AT  motion  performance.  The  out¬ 
puts  from  this  simulation  provided  an  initial  “feel”  for  how  the  arrangement  of  structural 
components  could  affect  the  system.  The  SIMS  A  T  configuration  used  for  momentum  wheel 
sizing  was  drawn  using  AutoCAD  (reference  Appendix  B,  Figure  B.l)  and  then  rendered 
(i.e.,  made  into  a  solid  or  wireframe  three-dimensional  image)  using  the  3D  Studio  VIZ 
software.  Figure  4.1314  shows  this  original  configuration  (referred  to  as  SIMSAT-0).  Read¬ 
ily  apparent  in  the  drawing  is  the  excessive  volume  needed  to  enclose  SIMSAT components. 
This  unnecessary  volume  needed  to  be  removed  to  reduce  the  system  moment  of  inertia 
and  improve  axis  symmetry. 

4-6.6  Structural  Development.  Beginning  with  the  next  structural  de¬ 
sign  iteration,  every  effort  was  made  to  reduce  SIMSAT  volume  and  position  components 
as  close  to  the  central  air-bearing  as  possible.  Figure  4.14  shows  the  SIMSAT- 1  config¬ 
uration,  the  first  attempt  at  establishing  a  logical  placement  of  components  to  support 
structural  design.  At  this  stage  of  development,  component  placement  was  accomplished 
without  actually  designing  a  supporting  structure;  structural  design  was  not  incorporated 
into  the  AutoCAD  models  until  later  in  this  design  subproblem.  SIMSAT  structural  de- 

14Reference  Appendix  B,  page  B-4,  for  identification  of  components  in  this  figure. 
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Figure  4.13  SIMS  AT-  Iteration  0 

sign  quickly  became  a  highly  integrated  process  where  equipment  constraints,  placement 
considerations,  and  structural  mass  minimization  were  intertwined  in  a  complex  fashion. 
The  classic  role  of  a  systems  engineer  as  designer  and  integrator  was  never  more  apparent 
than  during  the  SIMS  AT  structural  design  effort. 

No  attempt  will  be  made  to  fully  discuss  every  structural  design  iteration  attempted 
by  the  systems  engineering  team;  approximately  30  separate  design  drawings  were  produced 
as  the  structural  design  became  more  refined  and  system  decisions  were  made.  However, 
several  major  iterations  are  described  below  to  illustrate  important  shifts  in  thinking  with 
regard  to  component  placement  and  system-level  impacts. 

4-6. 6.1  Momentum  Wheel  Enclosure.  As  shown  in  the  SIMSAT- 1 
configuration,  the  three  momentum  wheels  were  originally  designed  with  separate  lexan 
enclosures.  This  allowed  for  maximum  modularity,  as  the  momentum  wheels  could  be 
separated  and  moved  to  opposite  sides  of  the  air-bearing  assembly.  Subsequent  examination 
of  this  arrangement,  however,  indicated  a  substantial  mass  penalty  was  incurred  (using 
separate  boxes)  without  any  significant  performance  improvements  realized.  Beginning 
with  SIMSAT- 3,  all  three  momentum  wheels  were  moved  into  a  single  enclosure,  with 
the  motors  attached  to  a  complex  shelf  support  structure.  This  shelf  support  structure 
represented  a  design  subproblem  in  which  the  momentum  wheels,  motors,  and  supporting 
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Figure  4.14  SIMS  AT-  Iteration  1 


elements  were  housed  in  as  tight  a  configuration  as  possible,  while  providing  adequate 
rigidity  to  mount  the  high  RPM  wheels  and  motors.  Figure  4.15  shows  the  SIMSAT-3 
configuration  in  wireframe  view.  In  addition  to  reducing  mass,  this  decision  also  had  the 
benefit  of  reducing  total  subsystem  volume,  although  at  the  expense  of  lumping  the  volume 
into  a  single  large  space  (impacting  subsystem  modularity). 

4.6. 6. 2  AutoBox  Orientation.  Another  major  configuration  decision 
involved  the  relative  placement  of  the  AutoBox  with  respect  to  the  structure.  As  one  of 
the  largest  subsystem  components,  the  AutoBox’s  orientation  would  be  a  driver  in  the 
structural  development.  Because  of  the  need  to  shock-mount  AutoBox  to  minimize  vibra¬ 
tion,  both  horizontal  and  vertical  AutoBox  mounting  schemes  were  examined.  SIMS  AT- A 
modeled  AutoBox  in  a  horizontal15  fashion  (see  Figure  4.16).  Attaching  the  AutoBox  to 
the  structure  horizontally  would  allow  the  rubber  shock-mounting  feet  supplied  with  the 
unit  to  be  used.  However,  this  approach  suffered  from  several  disadvantages.  First,  since 
SIMS  AT  has  the  ability  to  roll  upside-down,  an  additional  set  of  mounting  feet  would 
have  to  be  added  to  the  opposite  side  of  AutoBox  to  reduce  tension  loads  on  the  origi- 


16  “Horizontal”  implies  parallel  to  the  longitudinal  (roll)  axis  of  SIMSAT. 


Figure  4.15  SIMSAT-  Iteration  3 


nal  mounting  feet,  which  were  not  strong  enough  to  support  the  weight  of  the  AutoBox. 
Second,  mounting  the  AutoBox  horizontally  with  respect  to  the  long  axis  of  SIMSAT  in¬ 
terfered  with  the  truss  structure  as  it  was  then  envisioned;  a  non-standard  mounting  plate 
placed  orthogonal  to  all  the  other  mounting  plates  would  be  needed.  Finally  (and  most 
importantly),  a  moment  of  inertia  penalty  was  incurred  by  mounting  AutoBox  horizontally 
rather  than  vertically.  This  fact  drove  the  design  decision  to  mount  AutoBox  vertically 
with  respect  to  the  SIMSAT  long  axis. 

4.6.6. 3  Structural  Rod  Arrangement.  Both  box  (four  mounting  rods 
for  each  side)  and  prismatic  (three  rods)  structures  were  examined  for  mounting  SIMSAT 
components.  Prismatic  structures  were  quickly  abandoned  because  of  component  mount¬ 
ing  difficulties.  The  weight  savings  and  torsional  stiffness  provided  by  a  prismatic  shape 
were  outweighed  by  the  problem  of  mounting  rectangular  subsystem  components  to  non- 
rectangular  surfaces.  SIMSAT- 15  (see  Figure  4.17)  represents  a  fairly  mature  structural 
design  configuration.  The  size  of  the  momentum  wheel  box  dictated  the  overall  structural 
dimensions,  while  the  use  of  standard  mounting  plates  for  component  attachment  was  an 
intuitive  design  decision. 

4.6. 6.4  Battery  Arrangement.  The  three-battery  power  system  offered 
several  arrangement  possibilities.  Originally,  two  batteries  were  placed  on  the  payload  side, 
and  one  on  the  momentum  wheel  side.  However,  batteries  were  rearranged  in  this  iteration, 
with  one  battery  moved  from  the  payload  side  to  the  momentum  wheel  side.  This  allowed 
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Figure  4.16  SIMSAT-  Iteration  4 


Figure  4.17  SIMSAT-  Iteration  15 
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placement  of  the  gyros  and  wireless  communications  equipment  next  to  the  AutoBox, 
reducing  the  length  and  complexity  of  system  wiring.  Also  in  this  structural  iteration,  the 
AutoBox  was  reoriented  to  take  advantage  of  the  proposed  mounting  plate’s  rectangular 
shape  to  improve  its  shock-mounting  system.  Previously,  the  AutoBox  had  been  drawn 
to  extend  past  the  structural  envelope  defined  by  the  support  rods.  The  reorientation  of 
the  AutoBox  parallel  to  the  long  side  of  the  mounting  plate  (while  having  negligible  effect 
on  inertia  properties)  allowed  for  the  supplied  shock-mount  feet  to  once  again  be  used 
(additional  support  such  as  U-clamps  were  still  required). 

4‘6.6.5  Structural  Mass  Reduction.  Using  1/4”  aluminum  mounting 
plates  with  1/2”  aluminum  base  plates  rods  resulted  in  a  significantly  heavier  system 
structure  than  first  anticipated.  Some  means  of  reducing  the  total  weight  was  required. 
The  first,  and  most  easily  implemented,  weight-savings  decision  was  to  remove  the  air¬ 
bearing’s  mounting  disks  (supplied  with  the  air-bearing  system)  which  had  been  previously 
considered  for  structural  attachment.  Rather  than  mounting  onto  these  disks,  the  SIMS  AT 
structure  would  be  attached  directly  to  the  mounting  shafts  extending  from  the  central 
sphere.  Removal  of  the  circular  mounting  plates  immediately  reduced  overall  SIMS  AT 
mass  by  1081b  (each  disk  weighed  541b).  This  decision,  however,  reduced  the  available 
pitch  clearance  to  under  20  degrees  since  removal  of  these  mounting  disks  moved  the  base 
(innermost)  plate  inward  towards  the  central  sphere.  Additionally,  the  fastener  pattern  of 
the  air-bearing  mounting  shaft  would  be  required  to  secure  the  base  plate  to  the  shaft. 
These  screw  holes  were  too  close  to  the  center  of  the  base  plate  to  adequately  support 
the  shear  and  bending  loads  from  the  structural  mounting  rods  near  the  plate  edge.  A 
circular  collar  (redesigned  on  several  occasions)  was  added  to  SIMS  AT  to  increase  the 
distance  between  the  central  sphere  and  the  base  plate  and  provided  a  pitch  clearance  of 
approximately  22  degrees,  as  shown  in  Figure  4.18.  This  collar  also  allowed  a  wider  fastener 
pattern  to  the  base  plate,  aiding  in  the  load  support  of  the  plate.  These  circular  mounting 
collars  were  later  redesigned  to  include  a  recessed  portion.  This  recession  overlaps  the 
mounting  shaft  and  reduces  the  shear  load  experienced  by  the  mounting  shaft  screws. 
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Another  weight-savings  measure  was  to  re-examine  the  thickness  of  the  mounting 
plates.  Baseline  structural  estimates  did  not  include  holes  cut  into  the  mounting  plates 
to  save  weight.  It  was  decided  that  all  mounting  plate  estimates  would  assume  a  solid 
plate,  and  these  lightening  holes  could  be  added  in  later  design  as  subsystems  are  fitted 
to  the  plates  and  testing  of  the  system  is  underway16.  Various  plate  thicknesses,  rang¬ 
ing  from  3/32”  to  1/4”  were  ordered  and  submitted  for  mounting  plate  fabrication.  The 
appropriately-sized  plate  could  be  determined  should  system  testing  prove  a  plate  to  be 
over-  or  under-designed.  As  a  starting  point,  1/8”  plates  were  shown  (through  rough  cal¬ 
culations)  to  provide  adequate  stiffness  for  the  AutoBox  and  battery/gyro  plates,  resulting 
in  system  weight  savings. 


Figure  4.18  SIMSAT-  Iteration  23 

4-'6.6.6  Momentum  Wheel  Bay  Offset.  Although  most  of  the  struc¬ 
tural  design  was  set  by  the  SIMSAT- 23  configuration,  several  detailed  refinements  were 
added  to  improve  overall  performance.  Prior  to  this  stage  of  development,  the  center  of 

16Delaying  this  decision  was  obvious  since  cutting  holes  into  the  plates  is  an  easy  operation,  whereas 
a  redesign  would  be  required  if  the  plates  were  originally  designed  too  optimistically  (not  strong  or  stiff 
enough). 
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mass  of  the  momentum  wheel  bay  was  assumed  to  lie  on  the  geometric  center  of  the  box. 
Detailed  modeling  of  the  momentum  wheels,  lexan  box,  and  support  structure  refined  this 
location,  and  the  momentum  wheel  box  was  offset  (in  the  z-direction)  in  order  to  place 
the  momentum  wheel  bay  center  of  mass  on  the  SIMS  AT  roll  axis  (to  aid  in  balancing 
SIM  SAT). 

4-6.7  Structural  Implementation.  At  this  stage,  the  arrangement  of 
subsystem  components  was  fairly  complete  and  the  baseline  structural  design  was  devel¬ 
oped.  Before  fabrication  of  the  SIMS  A  T  structure  could  begin,  however,  several  key  issues 
still  required  resolution17.  The  remaining  structural  design  issues  are  summarized  in  the 
following  list: 

•  Specification  of  mounting  rod/plate  materials  and  dimensions,  as  well  as  mounting 
plate  fasteners. 

•  Determination  of  structural  responses  to  static  and  dynamic  loading. 

•  Design  of  a  supporting  truss  for  rigidity  to  meet  all  static  and  dynamic  requirements. 

•  Detailed  design  of  the  housing  and  mounting  of  all  subsystem  components,  to  include 
shock-mounting  and  vibration  suppression  for  sensitive  equipment. 

•  Design  of  a  payload  mounting  plate. 

•  Design  of  a  counterweight  system  to  aid  in  system  balancing. 

4.6.8  Baseline  Structure  Summary.  The  evolution  of  the  SIMS  AT 
structural  design  represented  an  important  milestone  towards  the  goal  of  successful  project 
completion.  The  use  of  CAD  tools  to  manipulate  component  configurations  was  crucial 
in  achieving  this  success.  Figure  4.19  shows  the  final  SIMSAT  design  as  presented  in  this 
document.  This  baseline  SIMSAT  structural  design  represents  a  robust  solution  balancing 
performance  needs  against  system  modularity  and  ease  of  use.  Chapter  V  and  Appendix 
K  further  describe  the  final  structural  design. 

17These  issues  axe  addressed  in  the  truss  design  subproblem  (Section  4.7),  the  final  structural  design 
appendix  (Appendix  K),  and  the  presentation  of  the  final  design  (Chapter  V). 
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Figure  4.19  SIMS  AT-  Final  Structural  Iteration 

4.7  Truss  Design 

4-7.1  Problem  Statement.  The  truss  design  problem  was  summarized  as 
follows: 

Using  the  basic  satellite  structure,  refine  the  structural  design  such  that  the  structure 
meets  static  and  dynamic  requirements. 
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4-7.2  Problem,  Scope.  At  this  stage  of  the  design,  the  structure  was  shown 
to  adequately  support  anticipated  loads  without  approaching  the  yield  strength  of  the  main 
aluminum  support  rods.  However,  a  static  analysis  to  determine  maximum  tip  deflections 
was  desired  to  ensure  that  the  structure  would  not  significantly  deform  under  loading, 
potentially  creating  undesirable  stress  concentrations.  Furthermore,  dynamic  analysis  was 
required  to  estimate  natural  frequencies  of  the  structure.  The  structure  can  then  be  stiff¬ 
ened  as  necessary  to  ensure  that  its  natural  frequencies  exceed  the  maximum  frequency 
of  the  motors/momentum  wheels.  In  this  way,  resonant  coupling  between  the  spinning 
momentum  wheels  and  the  structure  can  be  avoided.  Moreover,  a  more  rigid  structure 
would  provide  a  better  platform  for  use  in  vibration  experiments  and  other  experiments 
involving  flexible-structure  payloads. 

4.7.3  Requirements.  The  following  requirements  were  specified  to  ensure 
adequate  static  and  dynamic  structural  performance: 

•  Maximum  tip  deflections  should  not  exceed  10mm  under  static  loading  conditions. 

•  Natural  frequencies  of  each  side  of  the  structure  should  be  greater  than  maximum 
momentum  wheel  rotation  rates  (approximately  43Hz)  to  avoid  resonant  coupling. 
First-mode  frequency  should  exceed  60Hz  to  account  for  approximations  used  in  the 
dynamic  analysis. 

•  Slew  performance  should  not  be  compromised  by  the  truss  design. 

•  The  truss  should  easily  accommodate  the  addition  of  members  to  add  stiffness  should 
an  experiment  require  improved  rigidity. 

4 .7. 4  Value  System  Design.  For  this  portion  of  the  design,  a  detailed 
objective  hierarchy  was  considered  to  be  of  little  added  value  in  the  design  of  the  structural 
truss.  Instead,  objectives  were  identified  to  be  used  as  qualitative  evaluation  considerations. 
Designs  could  then  be  developed  and  considered  against  these  objectives,  followed  by  a 
decision  by  the  customer  based  on  a  presentation  of  the  more  favorable  truss  designs.  The 
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following  objectives,  ranked  by  order  of  importance,  were  identified  as  important  in  this 
segment  of  the  design: 

•  Meet  tip  deflection  requirements. 

•  Maximize  the  first  natural  frequency. 

•  Minimize  impacts  on  system  modularity. 

•  Minimize  added  structural  weight. 

•  Minimize  impacts  on  the  basic  structural  design. 

•  Minimize  impacts  on  slew  performance. 

•  Maximize  higher-order  natural  frequencies. 

•  Minimize  added  cost. 

4-7.5  Development  Approach.  The  rod-and-plate  structure  provided 
a  baseline  configuration  to  begin  the  truss  design.  A  worst-case  bending  deflection  was 
modeled  for  each  rod  to  provide  initial  estimates  of  the  material  and  size  of  the  rods.  A 
finite-element  analysis  package,  called  CADRE18 ,  was  used  in  the  static  and  dynamic  anal¬ 
yses.  Using  CADRE,  a  structural  model  of  each  side  of  the  SIMS  AT  was  built  using  nodes 
and  elements,  along  with  associated  loads  and  inertia  properties.  The  software  computed 
structural  static  and  dynamic  displacements,  internal  forces  and  moments,  and  displayed 
results  using  3-D  animation.  Once  the  rod-and-plate  structure  was  modeled,  static  dis¬ 
placements  and  natural  frequencies  were  then  determined  for  the  baseline  configuration. 
As  needed,  structural  elements  were  added  and  the  analyses  repeated. 

Unless  absolutely  needed,  it  was  desired  to  provide  structural  stiffness  without  re¬ 
arrangement  of  the  mounting  plates.  This  restriction  was  due  to  the  balancing  and  ar¬ 
rangement  of  components  on  the  mounting  plates.  The  truss  members  were  designed  and 
modeled  to  link  the  outsides  of  the  plate.  In  this  way,  interference  with  internal. compo¬ 
nents  and  wiring  paths  was  avoided,  and  the  basic  structural  design  was  left  intact.  Each 

18CADRE  Analytic  of  Issaquah,  WA,  produces  a  shareware  finite-element  package  called  CADRE ,  as 
well  as  the  professional  version  CADRE  Pro  [9]. 
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mounting  plate  could  be  drilled  with  holes  in  which  an  L-bracket  could  be  attached.  A 
bolt  through  the  L-bracket  would  be  used  as  the  cross-member  attachment  pin,  as  shown 
in  Figure  4.20.  This  assembly  allowed  easy  addition  and  removal  of  cross-member  supports 
as  necessary. 
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Figure  4.20  Linking  of  Truss  Members 

4-7.6  Finite- Element  Model.  A  49-node,  66-element  baseline  model  was 
constructed  for  each  side  of  the  SIMSAT.  The  payload-side  model  is  shown  in  Figure  4.21. 
The  following  assumptions  were  used  in  the  finite-element  analysis19.  Although  the  SIM¬ 
SAT  final  design  differed  slightly  in  element  specifications,  the  results  of  this  model  were 
still  applicable. 

•  Mounting  rods  are  represented  by  hollow  aluminum  tubes  of  outer  diameter  2.8cm 
and  0.5cm  thickness. 

19Appendix  L  lists  the  inputs  and  results  of  the  finite-element  modeling,  to  include  nodal  loads,  element 
properties,  and  static  deflections. 
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•  Mounting  plates  are  represented  by  eight  0.5cm  diameter  solid  aluminum  rods  in  a 
wire-frame  configuration  with  cross  members. 

•  Mounting  rod  mass  is  equally  shared  by  rod  nodes. 

•  Mounting  plate  mass  is  equally  shared  by  plate  nodes. 

•  Cross-member  support  elements  are  modeled  as  1.0cm  diameter  solid  aluminum  rods. 

•  Cross-member  support  elements  are  considered  massless.  20 

•  Cross-member  support  elements  are  drawn  from  the  rod/plate  juncture  (neglecting 
the  slight  offset  between  the  mounting  rod  and  the  end  of  the  plate). 

•  All  masses  are  modeled  as  point  masses  at  a  node,  except  for  the  component  masses 
at  the  plate  centers  which  are  offset  to  the  centers  of  gravity. 

•  Mounting  rods  are  affixed  cantilever  to  the  base  plates  with  one  end  clamped  (no 
degrees  of  freedom  at  joint). 

•  All  other  truss  joints  are  assumed  to  be  free  in  translation  and  rotation  (six  degrees 
of  freedom). 

•  An  18kg  payload  with  center  of  gravity  12cm  outside  of  the  payload  mounting  plate 
is  included. 

•  Static/ vibratory  response  is  modeled  for  each  side  of  SIMS  A  T  separately;  no  attempt 
is  made  to  model  the  dynamics  of  the  central  sphere  or  the  fully-joined  SIMS  AT 
structure. 

Static  Analysis.  Both  the  payload-side21  and  wheel-side22  structures 
exhibited  tip  deflections  less  than  2mm,  under  both  y-loading  (applied  along  the  longer 
dimension  [height]  of  the  structure)  and  z-loading  (applied  along  the  shorter  dimension 
[width]).  These  deflections,  calculated  using  the  CADRE  shareware  software,  were  for  the 

20A  55cm  rod  of  1.0cm  diameter  aluminum  weighs  0.12kg,  so  that  eight  support  rods  measure  less  than 
lkg  total,  which  is  considered  negligible. 

21  This  side  included  the  payload,  AutoBox,  battery,  gyros,  and  wireless  LAN. 

22This  side  included  the  momentum  wheel/motor  assembly  with  lexan  box,  along  with  two  batteries. 
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Figure  4.21  Finite-Element  Model  (Payload  Side) 


baseline  configurations  (no  additional  cross-members).  Thus,  no  structural  support  was 
necessary  to  meet  static  deflection  requirements. 

4-7.8  Payload- Side  Dynamics.  Dynamic  analysis  of  the  baseline  model 
indicated  that,  although  the  configuration  was  acceptable  for  static  deflection,  the  frequen¬ 
cies  of  the  lower  modes  were  inadequate  from  the  perspective  of  system  vibratory  response. 
The  first  three  modes  on  the  pay  load/ AutoBox-side  of  the  truss  occurred  at  16Hz  (sinu¬ 
soidal),  75Hz  (torsional),  and  98Hz  (double-sinusoidal),  respectively.  These  low  frequencies 
demonstrated  the  need  for  diagonal  cross-bracing  along  the  exterior  of  the  truss  to  increase 
structural  stiffness  and  raise  the  system’s  natural  frequencies. 

Seventeen  configurations  of  diagonal  bracing  were  evaluated  using  the  CADRE  soft¬ 
ware  package.  Cross-member  supports  along  the  top  of  the  structure  were  not  explicitly 
considered  because  the  lowest  frequency  responses  were  insignificantly  affected  by  such 
bracing,  and  the  AutoBox  wiring  would  be  impeded  by  such  design.  The  various  config¬ 
uration  models  are  displayed  in  Figure  4.22,  along  with  the  calculated  modal  responses. 


The  highest  first-mode  frequency  configurations  are  shaded.  In  all  cases,  diagonal  cross¬ 
member  supports  significantly  improved  the  vibratory  response  of  the  truss.  Based  upon 
discussions  with  the  decision  makers,  the  “double-X”  scheme  (shaded  as  “1”)  was  selected 
as  the  preferred  design  solution  for  the  payload-side  structure. 
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Figure  4.22  Truss  Configurations  (Payload  Side) 


4 .7.9  Wheel- Side  Dynamics.  Development  of  the  momentum  wheel  side 
of  the  SIMSAT  truss  proceeded  initially  in  a  similar  manner  to  the  development  of  the 


4-76 


Design  Mode  1/2/3  (Hz) 


20/66/72 

7 

s 

38/95/105 

7 

\ 

38/94/111 

7 

38/113/165 

Design  Mode  1/2/3  (Hz) 


Lexan  box  modeled  as  two  diagonal 
rods  on  each  side  of  the  truss  structure. 


Lexan  box  modeled  as  one  diagonal 
rod  on  each  side  of  the  truss  structure. 


▲ 

-  Top  and  bottom  cross-member  supports 


2-D  VIEW 
LEGEND: 


Base  Plate 


Cross-Member  Supports 
(1-Rod  Front  &  Back) 


Mounting  Rods 
Mounting  Plates 

Cross-Member  Supports 
(2-Rod  Front  &  Back) 


Figure  4.23  Truss  Configurations  (Momentum  Wheel  Side) 
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payload-side  truss.  Support  elements  were  again  modeled  as  1.0cm  diameter  rods.  The 
first  three  vibratory  modes  for  the  baseline  truss  (no  bracing  elements)  were  calculated  to 
be  20Hz  (sinusoidal),  66Hz  (torsional),  and  72Hz  (double-sinusoidal),  respectively.  Further 
analysis  indicated,  however,  that  diagonal  support  elements  would  not  be  as  effective  on 
the  momentum  wheel  side  of  the  truss  as  compared  to  the  payload  side.  Because  the 
lexan  box  surrounding  the  momentum  wheels  extended  beyond  the  truss  exterior  in  the 
z-dimension  (width),  vertical  cross-bracing  was  impeded  for  the  momentum  wheel  bay. 
Therefore,  cross-bracing  was  only  possible  along  the  interior  bays  of  the  truss,  and  along 
the  top  of  the  momentum  wheel  bay.  Neither  of  these  arrangements,  however,  significantly 
altered  the  first-mode  response  of  the  structure  to  meet  the  60Hz  minimum  requirement,  as 
shown  in  Figure  4.23.  To  illustrate  this  condition,  a  truss  using  support  elements  having  a 
modulus  of  elasticity  1000  times  greater  than  aluminum  only  yielded  a  first  mode  of  50Hz 
(shown  as  “1”).  Even  the  modeling  of  much  stiffer  mounting  rods  resulted  in  negligible 
modal  improvements.  The  momentum  wheel  model  did  not  include  the  stiffness  due  to 
the  lexan  box  itself,  however.  Inclusion  of  the  lexan  box,  modeled  to  behave  in  a  maimer 
approximating  diagonal  supports,  resulted  in  first  modes  of  71Hz  and  43Hz  for  alternate 
models  (shaded  as  “2”  and  “3”). 

4-7.10  Additional  Truss  Modeling.  Because  of  the  difficulty  in  modeling 
the  plates  and  lexan  boxj  the  CADRE  Pro  professional  version  was  procured  to  allow  a  more 
complete  finite-element  model  to  be  developed.  In  addition  to  the  basic  beam  modeling 
available  in  CADRE,  CADRE  Pro  allows  for  modeling  of  flat  plates,  using  2-D  triangular 
elements  to  build  plates  capable  of  carrying  in-plane  loads.  A  686-element  truss  model 
was  constructed  using  material  properties  of  updated  structural  components,  shown  in 
Figure  4.24.  Mounting  rods  were  represented  as  1”  304  stainless  steel  tubes  of  0.065”  wall 
thickness.  The  innermost  mounting  plate  (attached  to  the  air  bearing  collar)  was  modeled 
as  1/2”  2024  aluminum  plate,  with  the  remaining  plates  assumed  to  be  made  of  1/4”  2024 
aluminum.  The  deadweight  of  truss  elements  was  modeled  at  the  nodes  automatically  by 
CADRE  Pro.  Additional  SIMSAT  components  were  modeled  as  point  masses  located  at 
the  centers  (with  longitudinal  offset)  of  the  appropriate  mounting  plates. 
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Figure  4.24  Finite-Element  Model  Using  Plates 


Analysis  of  this  improved  model  indicated  that  static  deflections  were  negligible  (less 
than  0.1mm).  Vibratory  response  was  noticeably  improved  in  comparison  to  the  original 
beam  element-only  model.  The  first  three  modes  of  the  new  model  were  94Hz,  144Hz, 
and  430Hz,  respectively.  The  results  indicated  that  modeling  of  2-D  plates,  which  axe 
structurally  stiffer  than  their  beam  analogs  used  in  the  CADRE  model,  provided  a  less 
conservative  estimate  of  the  lowest  mode  frequency.  The  absolute  certainty  of  these  values 
was  still  unknown,  however,  due  to  the  inability  of  both  CADRE  and  CADRE  Pro  to  fully 
model  the  complete  SIMSAT  structure  as  designed.  Discussions  with  the  decision  makers 
indicated  their  belief  that  vibration  of  individual  components  (most  notably  the  AutoBox) 
separate  from  the  truss  itself  may  drive  the  determination  of  system  natural  frequencies. 
Therefore,  additional  finite-element  modeling  of  the  system  was  determined  to  be  of  limited 
value  for  further  design  decisions. 

4 .7. 11  Truss  Structure  Summary.  The  results  of  the  finite-element 
analyses  directly  impacted  design  decisions  made  regarding  the  truss  structure.  It  was 


decided  that  diagonal  cross-bracing  elements  would  be  added  to  the  design  to  ensure  suffi¬ 
cient  structural  rigidity  to  prevent  vibratory  coupling  and  resonance.  The  models  clearly 
supported  the  improved  rigidity  benefits  of  additional  cross-member  supports  in  this  de¬ 
sign.  All  mounting  plates  would,  therefore,  be  drilled  to  fit  L-bracket  attachments  so  that 
cross-braces  may  be  added  or  removed  as  necessary.  Further  discussions  with  the  decision 
maker  indicated  a  desire  to  make  the  structure  as  stiff  as  reasonably  possible,  aiming  for  a 
100Hz  minimum  mode  frequency  rather  than  the  60Hz  minimum  initially  required.  To  this 
end,  multiple  thicknesses  of  aluminum  (1/2”,  1/4”,  1/8”,  3/16”,  and  3/32”)  were  purchased 
as  available  sheet  stock  to  be  used  as  mounting  plates.  The  final  determination  of  which 
elements  (plates  and  stiffeners)  to  use  in  the  baseline  configuration  would  be  determined 
after  experimentation  and  empirical  testing.  As  a  starting  point,  the  “double-X”  and 
“single- X”  support  schemes  would  be  used  for  the  payload-side  and  wheel-side  structures, 
respectively.  The  modularity  of  the  structural  configuration  would  easily  accommodate 
additional  cross-members,  use  of  other  cross-member  rods  (such  as  hollow  steel),  or  use  of 
stiffer  mounting  plates. 


4' 8  Wireless  Communications  Selection 

4-8.1  Problem  Statement.  The  following  design  subproblem  was  the  focus 
of  this  Detailed  Design  iteration: 

Select  a  preferred  commercial- off-the-shelf  (COTS)  wireless  communications  system, 
to  include  wireless  LAN  and  wireless  modem  for  transmission  of  command  and  telemetry 
data  /Cockpit,  Trace,  and  RealMotion  data). 

4-8.2  Problem  Scope.  In  the  Preliminary  Design  phase,  an  all-onboard 
(using  dSPACE’s  AutoBox)  processing  option  was  selected.  This  processor  would  collect 
and  process  sensor  data,  receive  commands  from  the  ground  station,  process  control  laws 
real-time,  issue  inputs  to  onboard  systems,  and  transmit  telemetry  data  to  the  ground 
station  (Simulation  PC).  The  wireless  communications  system  to  link  the  AutoBox  with 
the  ground  station  would  be  COTS-designed,  as  determined  in  the  Preliminary  Design 
phase.  With  this  background,  this  design  subproblem  focused  on  identifying  communica- 
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tions  constraints,  developing  rationale  for  system  selection,  and  finally  selecting  preferred 
wireless  LAN  and  wireless  modem  systems  for  SIMS  AT  integration.  Identification  of  spe¬ 
cific  vendors  and  model  numbers  was  the  final  output  of  this  subproblem. 

4-8.3  Constraints.  The  10Mbps  Ethernet  connection  required  for  ground- 
station-to-AutoBox  connectivity  imposed  several  constraints  on  the  wireless  communica¬ 
tions  system.  In  addition,  onboard  power  system  constraints  were  specified  to  ensure 
feasibility.  The  following  list  identifies  the  wireless  communications  constraints  used  to 
narrow  the  communications  solution  space: 

•  Wireless  systems  must  be  commercially  available. 

•  The  wireless  LAN  must  provide  a  10Mbps  Ethernet  connection  for  Cockpit  and 
Trace  data. 

•  The  wireless  modem  must  provide  serial  data  transmission  at  adequate  transmission 
speed  for  RealMotion  data.23 

•  The  AutoBox  requires  ISA-compatible  network  cards. 

•  Wireless  systems  must  operate  using  a  DC  power  supply  (36V  maximum). 

•  As  accounted  for  in  power  budgets,  power  consumption  should  not  exceed  5W. 

•  For  safety  and  RF  interference  considerations,  only  systems  designed  for  indoor  use 
will  be  implemented. 

•  RF  transmission  must  use  FCC-approved  frequency  bands. 

•  Because  of  the  changing  antenna  orientation  during  SIMSAT  operation,  wireless 
systems  must  use  omnidirectional  antennas. 

4.8.4  Value  System  Design.  To  provide  a  basis  for  the  evaluation  of 
communications  system  alternatives,  the  following  system-level  considerations  were  identi¬ 
fied.  These  considerations  are  ranked  by  order  of  importance  in  system  selection.  A  formal 

23  Since  the  RealMotion  data  is  neither  mission-critical  nor  high- volume,  a  specified  connection  speed 
was  not  a  constraint. 
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objective  hierarchy  was  not  needed  as  these  evaluation  considerations  provided  sufficient 
direction  for  the  wireless  selections. 

•  Integration.  Minimization  of  integration  complexity  is  desired.  Models  offering 
AutoBox-compatible  connections  are  preferred. 

•  Weight  and  Volume.  Minimization  of  the  weight  and  volume  of  the  communications 
subsystem  is  desired. 

•  Data  Transmission.  Wireless  LAN  data  rates  exceeding  the  10Mbps  constraint  pro¬ 
vide  no  performance  advantage,  as  the  Ethernet  data  is  sent  at  only  10Mbps  by  the 
AutoBox.  Faster  wireless  modem  speeds  provide  some  performance  advantage. 

•  Cost  and  Delivery.  Minimization  of  communications  subsystem  cost  is  desired. 
Shorter  delivery  times  are  preferred. 

•  Power  Consumption.  Less  power  consumption  is  desired. 

•  Vendor  Reputation.  Research  into  a  vendor’s  reputation,  based  on  objective  sources, 
can  be  used  to  differentiate  wireless  models,  as  necessary  or  applicable. 

•  Warranty.  Longer  system  warranties  are  preferred. 

•  Transmission  Power.  All  indoor  wireless  designs  are  considered  safe  for  laboratory 
usage;  thus,  minimization  of  transmission  power  provides  minimal  safety  and  RF 
interference  benefits. 

4-8.5  Wireless  Background  Sources.  The  design  team  first  con¬ 
tacted  dSPACE,  Inc.,  directly  to  inquire  about  dSPACE/AutoBox  wireless  applications 
by  dSPACE  customers.  Apparently,  only  one  other  wireless  AutoBox  application  had 
been  accomplished  to  dSPACE’s  knowledge.  Engineering  students  at  the  Ohio  State  Uni¬ 
versity  had  linked  several  AutoBoxes  using  wireless  modems  to  transfer  low-speed  serial 
data.  Through  contact  with  these  engineers,  it  was  learned  that  their  application  did  not 
involve  Cockpit,  Trace,  or  RealMotion  data,  and  their  laboratory  had  only  one  Au¬ 
toBox  remaining  [47].  Thus,  an  existing  wireless  AutoBox  solution  comparable  to  the 
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SIMS  AT  application  was  not  found,  making  the  SIMS  AT  design  somewhat  of  a  pioneer  in 
AutoBox  wireless  networking24. 

COTS  wireless  system  alternatives  were  then  explored  using  Internet  searches  and 
publications  research25.  By  applying  the  system  constraints  to  this  solution  space,  the 
number  of  alternatives  was  reduced  from  several  hundred  to  only  a  handful. 

4*8.6  Wireless  LAN  Alternatives .  The  major  driver  in  reducing  the 
wireless  LAN  solution  space  was  the  10Mbps  Ethernet  capability.  Six  10Mbps  system  ven¬ 
dors  were  discovered.  Of  these  six,  four  vendors  offered  wireless  LAN  bridges  primarily  for 
outdoor  use.  Further  research  indicated  that  the  transmission  powers  and  RF  interference 
for  these  outdoor  designs  did  not  pose  as  great  a  problem  as  first  predicted.  In  fact,  some 
of  these  outdoor  designs  were  advertised  for  indoor  use  as  well.  Thus,  more  information 
on  wireless  bridge  designs  was  required  to  determine  their  feasibility  for  SIMS  AT  use. 

4-8.6. 1  Wireless  LAN  Bridges.  The  WaveSpan  5800 ,  offering  10Mbps 
connectivity  for  up  to  5  miles,  was  considered  a  baseline  wireless  LAN  bridge.  Priced 
at  $23,950  per  link  [12:103],  this  system  was  considered  far  too  expensive  for  SIMS  AT 
integration.  Furthermore,  the  wireless  bridge  solutions  were  designed  to  link  one  LAN  to 
another  LAN,  instead  of  a  peer-to-peer  architecture  desired  between  the  ground  station 
and  the  satellite.  For  these  reasons,  the  wireless  bridge  solutions  were  no  longer  considered 
for  the  communications  function. 

4-  8. 6. 2  Office- Use  Wireless  LANs.  Two  wireless  LAN  solutions  re¬ 
mained:  the  Aironet  4800  Turbo  DS  Series  (11Mbps)  and  the  RadioLAN  product  series 
(10Mbps).  As  described  in  Section  4.2.6.6,  page  4-15,  the  Aironet  AP4800  and  RadioLAN 
ISA  CardLINK  are  very  similar  in  transmission  capability,  mass,  size,  and  power.  How¬ 
ever,  additional  research  showed  that  the  PC-card  interface  of  the  Aironet  model  would  be 

24  As  an  unproven  technology  application,  the  wireless  LAN  involved  system  risks  which  were  .conveyed 
to  the  decision  makers. 

25  An  excellent  source  for  wireless  product  information  was  the  Ottawa  Amateur  Radio  Club  website  [42], 
with  specifications  and  company  information  for  over  150  different  wireless  systems. 
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very  difficult  to  integrate  with  the  ISA-compatible  design  of  the  AutoBox.  Therefore,  the 
RadioLAN  product  series  was  selected  over  the  Aironet  model  for  continued  investigation. 

RadioLAN  offers  several  wireless  systems  in  its  10Mbps  product  series:  BackboneLINK 
208,  ISA  CardLINK  101,  PC  CardLINK  130,  and  DockLINK  408™.  All  four  options  offer 
Ethernet  connectivity  through  an  omnidirectional  radio  transceiver  unit,  but  each  op¬ 
tion  was  intended  for  a  different  network  application.  The  BackboneLINK  was  designed 
as  a  stand-alone  wireless  hub  for  multi-user  wireless  networking,  priced  around  $1,00027. 
The  ISA  CardLINK  ($349)  is  the  standard  user  (desktop)  access  link,  whereas  the  PC 
CardLINK  ($449)  was  designed  for  laptop  users.  Finally,  the  DockLINK  ($799)  serves  as 
a  transparent  bridge  for  Ethernet-enabled  network  devices,  such  as  UNIX  workstations, 
printers,  and  Macintosh  workstations. 

Initial  analysis  revealed  that  a  BackboneLINK  would  not  be  required  for  the  SIMS  AT 
design  ;  a  peer-to-peer  link  would  suffice.  As  with  the  Aironet  model,  the  PC  CardLINK 
was  ruled  out  due  to  the  PC-card  interface.  Thus,  only  the  ISA  CardLINK  and  Dock¬ 
LINK  alternatives  remained  for  consideration  -  a  CardLINK-CardLINK  (ground-satellite) 
architecture  versus  a  CardLINK-DockLINK  architecture.  The  DockLINK  is  shown  in  Fig¬ 
ure  4.25. 

The  ISA  CardLINK  included  software  required  to  install  network  drivers  for  wireless 
networking.  Since  the  AutoBox  does  not  contain  a  floppy-disk  drive,  further  research 
was  required  to  determine  the  feasibility  of  the  CardLINK  onboard  the  satellite.  Initial 
conversation  with  dSPACE  engineers  indicated  that  a  “burn-in”  of  these  drivers  could  be 
made  on  the  AutoBox,  either  at  dSPACE’s  facility  or  by  the  design  team  using  a  flashdrive 
configuration.  However,  the  technical  support  representative  at  RadioLAN  stated  that 
although  the  network  drivers  could  be  loaded  onto  the  AutoBox  processing  board,  an 
operating  system  (Windows  95/98)  was  needed  to  actually  enable  the  wireless  network. 
His  recommendation  was  that  the  DockLINK  was  better  suited  for  onboard  installation, 
providing  a  “dumb”  network  bridge.  Since  the  DockLINK  was  intended  for  office  -use  in  a 
constant  orientation,  its  application  in  the  SIMS  AT  design  presented  risks,  such  as  loss  of 

2 6 Each  RadioLAN  device  is  described  on  the  RadioLAN  website,  www.radiolan.com. 

27Product  prices  according  to  PC  Magazine,  1  September  1998  [57]. 
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Figure  4.25  RadioLAN  DockLINK  Model  408  [45] 


data  or  subsystem  failure.  With  the  omnidirectional  antenna,  the  RadioLAN  technician 
determined  the  risk  of  data  dropout  to  be  minimal  at  the  very  short  ranges  required  by 
SIMS  AT  (approximately  10  ft).  Shock-mounting  of  the  transceiver  onboard  the  satellite 
adequately  negated  the  risk  of  system  failure  due  to  an  unsteady  environment.  Table  4.10 
describes  the  specifics  for  both  the  ISA  CardLINK  and  the  DockLINK. 


Table  4.10  RadioLAN  Product  Data  [45] 


Parameter 

ISA  CardLINK 

DockLINK 

Purchase  Cost 

$349 

$799 

Radio  Frequency 

5.8GHz  ISM  band 

5.8GHz  ISM  band 

Transceiver  Weight 

9.8oz  (278g) 

7.4oz  (206g) 

Unit  Weight 

4.6oz  (130g) 

22.3oz  (632g) 

Input  Power 

5V/12V 

12V  (or  110VAC) 

Transmission  Power 

50mW  peak 

50mW  peak 

Media  Access  Protocol 

CSMA/CA 

CSMA/CA 

Network  Interface 

16-bit  ISA 

RJ-45  jack 

Warranty 

1  yr  (parts  &  labor) 

1  yr  (parts  &  labor) 

4-8.7  Wireless  LAN  Selection.  Based  on  the  wireless  LAN  research  and 
analysis,  the  selected  wireless  LAN  architecture  included  a  ground-based  ISA  CardLINK 
with  transceiver  and  a  satellite-based  DockLINK  with  transceiver.  Because  the  wireless 
LAN  is  relatively  inexpensive  and  a  “tight”  subsystem  (in  that  its  interfaces  are  few  and 
well-defined)  replacement  of  this  RadioLAN  architecture  with  a  different  model  should  not 
be  significantly  difficult.  Thus,  an  alternative  wireless  LAN  can  be  implemented  without 
significant  system  impacts  should  the  RadioLAN  system  prove  to  have  unforeseen  draw¬ 
backs,  or  a  more-capable  system  becomes  available  at  a  later  date.  As  the  technology 
expands,  the  future  of  wireless  LANs  will  certainly  see  more  10Mbps  systems  on  the  mar¬ 
ket,  including  the  Bluetooth  2.4GHz  model  scheduled  for  release  late  in  1999  [27].  Thus, 
the  risks  associated  with  the  implementation  of  this  wireless  LAN  in  an  untested  appli¬ 
cation  were  considered  acceptable.  The  RadioLAN  ISA  CardLINK  and  DockLINK  were 
approved  and  ordered. 

4-8.8  Wireless  Modem  Considerations.  As  stated  previously,  the 
incorporation  of  the  wireless  modem  was  not  critical  to  SIMS  AT  operation.  The  wireless 
modem  was  to  provide  the  communications  link  for  the  RealMotion  data  stream,  which 
allowed  3-D  animation  capability  but  was  not  used  for  data  collection  or  control  processing. 
With  the  schedule  constraints  imposed  on  the  baseline  design,  integration  of  the  wireless 
modem  for  this  function  was  determined  to  be  of  secondary  priority.  Wireless  modems  were 
investigated  and  a  vendor  (including  model)  was  selected,  but  purchase  and  integration 
were  delayed  until  after  the  wireless  LAN  was  successfully  integrated28.  This  decision  was 
based  on  several  factors: 

•  Integration  of  the  wireless  LAN  was  critical  to  system  operation,  whereas  integration 
of  the  RealMotion  communications  link  was  not. 

•  Integration  of  the  wireless  LAN  would  provide  greater  knowledge  of  omnidirectional 
antenna  capabilities  on  a  rotating,  laboratory-based  satellite.  This  knowledge  may 

28The  wireless  LAN  system  was  received  in  late  January,  1999.  Integration  of  the  LAN  was  not  complete 
before  this  document  went  to  print. 
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significantly  impact  the  choice  of  wireless  modem  system  as  problems  and  solutions 
related  to  antenna  interference  are  encountered. 

•  Being  a  COTS  subsystem,  order  and  delivery  of  a  wireless  modem  would  require 
minimal  time,  and  relative  to  other  subsystems,  the  costs  of  a  wireless  modem  would 
not  be  great. 

•  Integration  of  the  wireless  LAN  would  set  the  data  architecture,  and  a  wireless  mo¬ 
dem  could  more  easily  be  integrated  as  a  “plug-and-play”  component. 

•  As  a  general  design  rule,  making  system  decisions  before  they  are  necessary  often 
results  in  increased  financial  and  technical  risks. 

4-8.9  Wireless  Modem  Alternatives.  With  a  large  number  of  wireless 
modem  vendors  available,  certain  criteria  were  required  to  reduce  the  number  of  subsys¬ 
tem  alternatives.  The  first  constraint  used  in  selection  was  to  only  consider  those  models 
designed  for  telemetry  data  acquisition.  This  decision  was  based  on  the  assumption  that 
a  modem  developed  for  industrial/ telemetry  applications  would  be  less  risky  to  integrate 
into  the  SIMSAT  design  than  a  modem  designed  for  office  PC  applications,  such  as  wire¬ 
less  internet  or  wireless  networking.  Because  of  the  team’s  limited  knowledge  of  wireless 
applications,  it  was  also  desired  to  consider  vendors  who  offered  easy  accessibility  and 
quick  response  time  to  technical  questions.  This  subjective  measure  was  important  be¬ 
cause  SIMSAT  involved  unique  data  transmission  problems,  as  the  onboard  transceiver 
would  be  in  motion.  Thus,  interaction  with  technical  support  was  essential  to  identify  and 
solve  integration  issues. 

Based  on  these  constraints,  several  wireless  modem  designs  were  available.  One 
promising  alternative  was  the  SkyLine  Wireless  Modem  of  Sonik  Technologies  Corpora¬ 
tion,  San  Marcos,  CA.  This  model,  designed  for  radio  control  and  data  acquisition  ap¬ 
plications,  featured  a  sophisticated  communications  processor  which  uses  a  powerful  and 
efficient  communications  protocol  developed  by  Sonik  to  reduce  multipath,  RF  interfer¬ 
ence,  intermodulation,  and  signal  fade  problems.  Operating  at  9600  bps  over  the  air,  the 
modem  uses  an  RS-232  interface  which  can  be  configured  to  connect  to  the  AutoBox. 
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Specifications  include  2W  RF  power  output,  a  range  of  frequency  bands  (up  to  512MHz), 
12.5V  DC  power  requirements,  and  a  3.0”  x  3.0”  x  1.5”  size  [52].  The  quoted  cost  of  this 
modem  was  $599  each.  Figure  4.26  shows  the  Sonik  Skyline  modem. 


Figure  4.26  Sonik  Technologies  Corporation’s  Skyline  Modem  [52] 

A  second,  more  promising,  alternative  was  the  WIT2400M  of  Digital  Wireless  Corpo¬ 
ration  (DWC),  Norcross,  GA.  This  modem,  operating  in  the  2.4GHz  range,  offered  greater 
data  throughput  (up  to  115  kbps)  due  to  the  higher  transmission  frequency29.  With  a  lower 
output  power  than  the  SkyLine  modem,  specified  at  lOmW  or  lOOmW,  less  RF  interfer¬ 
ence  with  the  wireless  LAN  system  was  anticipated.  The  WIT2400M  also  incorporates  an 
RS-232  interface  to  the  AutoBox.  The  modem  requires  a  5.5V  to  10V  power  supply,  with 
operating  currents  up  to  150mA  (typical).  Prices  start  at  $590  per  modem.  [14] 

Conversation  with  the  DWC  technical  support  representative,  Mr.  Don  Neas,  re¬ 
vealed  that  a  development  kit  was  available  from  DWC  which  would  suit  the  SIMSAT 
application  quite  well.  The  development  kit  ($2250)  included  a  pair  of  modems  equipped 
with  power  supplies,  battery  packs,  battery  charger,  flow  control  indicators,  dipole  anten- 

29Use  of  a  2.4GHz  wireless  LAN  should  not  be  used  with  this  modem  due  to  interference  concerns. 
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nas,  RS-232  interface,  configuration  software,  and  technical  support.  Figure  4.27  shows 
the  packaged  unit  (called  the  WIT2400E).  Small  in  size  (4.5”  x  6”  x  1.5”)  and  lightweight 
(approximately  1kg),  this  modem  alternative  could  be  integrated  with  minimal  complexity 
as  a  stand-alone,  self-powered  subsystem.  Experience  with  the  DWC  technical  support 
showed  that  response  to  questions  was  quick  and  complete.  With  the  short  transmission 
ranges  required  by  SIMS  AT  (approximately  10  ft),  Mr.  Neas  believed  that  data  dropouts 
due  to  polarization  fading  would  be  minimal  as  signal  transmission  via  reflection  at  these 
short  ranges  was  adequate.  Thus,  loss  of  signal  due  to  SIMS  AT  motion  was  not  anticipated. 


Figure  4.27  Digital  Wireless  Corporation’s  WIT2400E  Modem  [14] 

4-8.10  Wireless  Modem  Selection.  The  WIT2400  Developer’s  Kit 
from  Digital  Wireless  Corporation  was  selected  for  SIMSAT  implementation.  From  an 
integration  perspective,  this  option  did  not  require  incorporation  of  the  wireless  modem  into 
the  power  architecture,  and  it  incorporated  an  RS-232  interface  to  the  AutoBox.  Software 
could  be  used  to  adjust  modem  settings  from  a  standard  PC  station  before  integration 
onboard  the  satellite.  Thus,  this  alternative  was  determined  to  be  easy  to  integrate  into 
the  system.  With  a  next-day  delivery  time,  acquisition  of  the  kit  was  not  time-critical.  For 
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these  reasons,  the  kit  was  selected  for  SIMS  AT  use,  but  was  not  ordered  early  in  system 
integration. 


4.9  Subsystem  Integration 

4  *9.1  Problem  Statement.  The  integration  subproblem  is  summarized 
below: 

Based  on  the  selected  subsystems  and  structural  design ,  develop  an  integration  strat¬ 
egy  for  the  power  and  signal  interfaces  of  each  subsystem . 

4-9.2  Problem  Scope.  Because  of  the  limited  design  schedule  and  late 
delivery  of  some  system  components,  full  integration  of  the  SIMS  AT  architecture  was 
not  possible  before  publication  of  this  document.  Thus,  this  design  iteration  focused  on 
considering  integration  issues,  identifying  subsystem  interfaces,  and  developing  power  and 
communications  architectures.  This  section  does  not  include  actual  system  integration, 
test,  or  evaluation.  At  this  stage,  laboratory  technicians,  technical  support  representatives, 
and  design  advisors  played  a  key  role  in  system  development. 

4*9.3  Power  Interface  Issues.  The  following  power- related  tasks  were 
identified  for  consideration  in  this  design  phase: 

•  Developing  the  overall  electrical  bus  architecture. 

•  Determining  wire  gauges. 

•  Providing  capability  to  monitor  power  usage. 

•  Providing  payload  power  interfaces. 

•  Grounding  the  satellite. 

•  Reducing  RF/electromagnetic  interference  (RFI/EMI). 

4-9.4  Signal  Interface  Issues.  The  following  signal-related  tasks  were 
identified  for  consideration  in  this  design  subproblem: 
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•  Providing  payload  signal  interfaces  to  the  AutoBox. 

•  Momentum  wheel  assembly  integration  (to  include  connecting  motors  and  amplifiers, 
and  connections  to  the  AutoBox). 

•  Calibrating  the  gyros. 

•  Receiving  data  from  the  gyros. 

•  Connecting  the  wireless  LAN  to  the  AutoBox. 

•  Connecting  the  wireless  modem  to  the  AutoBox. 

4 .9. 5  Power  System  Architecture.  Early  in  Detailed  Design,  it  was 
decided  to  use  the  Power-Sonic  line  of  sealed  lead  acid  batteries  to  meet  system  power 
requirements.  From  this  starting  point,  detailed  design  of  the  power  subsystem  began  in 
earnest.  Major  integration  issues  involving  operating  voltages,  current  protection,  wire 
gauge,  power  consumption,  and  other  interfaces  surfaced  during  this  phase  of  design.  The 
power  subsystem  changed  several  times  during  the  course  of  detailed  design  as  power 
requirements  were  added,  modified,  or  deleted. 

4-9. 5.1  Bus  Voltage  Determination.  At  the  beginning  of  power  sys¬ 
tem  development,  the  baseline  SIMS  AT  operating  voltage  was  initially  set  at  24V  DC. 
This  voltage  provided  acceptable  operating  conditions  for  the  momentum  wheel  motors 
and  AutoBox.  The  NEJ-3000  Piezo  Electronic  Gyro  System  (Horizon  gyro)  was  originally 
determined  to  require  a  dedicated  4.8V/50mA  dry  cell  power  supply  for  optimum  system 
performance;  however,  this  item  was  subsequently  deferred  in  favor  of  the  Humphrey  he¬ 
licopter  gyro  package  in  the  Detailed  Design  first  iteration.  Power  requirements  for  the 
communications  subsystem  were  estimated  as  12V/50mA  for  a  typical  arrangement. 

The  24V  operating  voltage  allowed  for  two  12V  batteries  to  be  placed  in  series, 
achieving  the  required  voltage  to  operate  the  momentum  wheel  motors.  Minimum  operat¬ 
ing  voltage  for  the  motor  was  listed  at  20V,  although  initial  experimentation  with  a  similar 
motor  by  the  same  manufacturer  (the  SmartMotor)  indicated  that  a  voltage  slightly  higher 
than  this  value  was  required  for  consistent  operation.  Experimentation  with  AutoBox  con- 
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firmed  8  to  36V  autoranging  operation,  although  a  minimum  15V  for  system  startup  was 
required  prior  to  operation  at  lower  voltages.  AutoBox  power  draw  remained  a  constant 
60W  throughout  the  range  of  operating  voltages. 

An  additional  factor  considered  during  design  of  the  power  subsystem  involved  poten¬ 
tial  requirements  of  experimental  systems  not  included  in  the  baseline  design.  An  example 
of  this  integration  issue  was  the  cold-gas  thruster  system  planned  for  eventual  implemen¬ 
tation.  The  operating  voltage  range  of  the  Moog  Model  50-673  Cold  Gas  Thruster  Triad 
is  24  V  to  32  V;  if  SIMS  AT  were  operating  only  at  a  maximum  voltage  of  24V,  the  system 
would  not  be  robust  enough  to  support  thruster  operation  for  more  than  the  first  few 
minutes  of  the  experiment.  This  situation  would  occur  as  battery  power  was  drawn  down 
and  the  output  voltage  dropped  below  24V30. 

Given  these  conflicting  requirements,  it  was  decided  to  consider  both  24V  and  36V 
operating  bus  voltages  for  the  SIMS  AT  baseline.  A  system- level  trade  study  conducted 
earlier  in  this  phase  of  the  design  indicated  a  clear  preference  for  a  36V  bus  voltage.  This 
voltage  alleviated  any  concerns  regarding  insufficient  operating  voltage  for  any  hardware 
contemplated  for  eventual  SIMS  AT  use.  Additionally,  a  multiple  power  bus  architecture 
was  decided  upon  for  the  baseline  power  design.  Since  power  would  be  supplied  by  12V 
batteries,  it  would  be  possible  to  wire  three  batteries  in  series  to  provide  a  full  36V,  or 
place  components  in  series  with  only  one  or  two  batteries  to  obtain  12V  or  24V  power. 
This  arrangement  allowed  the  greatest  flexibility  in  matching  varying  component  interfaces. 
Figure  4.28  shows  the  original  wiring  diagram  developed  at  this  stage  of  the  design. 

4-9. 5. 2  Wire  Gauge  Selection.  Standard  electrical  handbooks  were 
consulted  to  determine  the  wire  gauge  needed  for  safe  operation.  The  maximum  current 
drawn  by  each  component  was  estimated  (shown  in  Table  4.11)  and  compared  to  data 
from  the  American  Electrician’s  Handbook  [10].  This  reference  indicated  that  18  gauge 
wire  would  be  sufficient  for  basic  system  wiring  needs.  The  exception  to  this  design  would 
be  motor /amplifier  wiring  due  to  the  large  currents  anticipated.  A  minimum  12  gauge  was 

30For  this  reason,  the  36V  Baseline  Bus  Availability  metric  was  used  in  the  first  Detailed  Design  system 
evaluations. 
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Figure  4.28  Initial  Wiring  Diagram 

determined  to  be  sufficient  between  the  batteries  and  the  amplifiers,  while  slightly  lighter 
wire  (14  gauge)  would  suffice  between  the  amplifiers  and  the  motors.  This  design  decision 
reflected  a  tradeoff  between  a  worst-case  possibility  and  expected  operating  performance. 


Table  4.11  Power  Estimates  Used  for  Wire  Sizing 


Component 

Current  (A) 

Voltage  (V) 

Power  (W) 

Minimum  Wire  Gauge 

AutoBox 

2.5 

24 

60 

18 

20 

36 

720 

12/14 

0.5 

12 

6 

27 

Gyro 

1.78 

28 

50 

18 

Thrusters 

0.75 

32 

24 

18 

Assuming  the  theoretical  situation  in  which  all  three  motors  were  simultaneously 
drawing  maximum  current,  wiring  extending  from  the  battery  terminals  would  need  to 
be  rated  for  a  maximum  60A  current.  Such  wiring  would  be  unacceptable  for  SIMS  AT 
use,  due  to  its  inherent  bulk,  thickness,  inflexibility,  and  internal  resistance.  A  more  likely 
situation  would  be  infrequent  maximum  power  output  to  a  single  motor,  with  light  to 
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moderate  current  supplied  to  the  remaining  motors.  These  power  events  would  likely 
last  for  only  a  few  seconds  (perhaps  up  to  30  seconds),  with  maneuvers  alternately  led 
by  different  motors  in  an  unpredictable  fashion.  This  situation  would  effectively  lead  to 
pulses  of  current  flowing  through  the  motor/amplifier  leads,  allowing  some  time  for  heat 
dissipation.  For  this  reason,  motor/amplifier  wire  sizing  is  based  upon  a  nominal  20A 
continuous  current,  thereby  permitting  the  use  of  thinner  wire  compared  to  the  worst-case 
situation. 

Tables  4.12  and  4.13  provide  representative  values  for  short-time  ratings  of  aircraft- 
grade  cables  [55];  these  results  support  the  system  design  decision.  It  should  be  noted, 
however,  that  bundling  of  cables  reduces  the  maximum  rating  due  to  the  decreased  heat 
dissipation  from  shared  surface  areas. 

Table  4.12  Maximum  5min  Rating  (Amperes)  for  Aircraft- Grade  Cables  in  Free  Air 


AWG  Size  (approx.) 

1  Cable 

3  Cables 

7  Cables 

12  Cables 

22 

12 

8 

7 

6 

16 

25 

19 

14 

13 

10 

71 

56 

48 

45 

Table  4.13  Maximum  lmin  Rating  (Amperes)  for  Aircraft- Grade  Cables  in  Free  Air 


AWG  Size  (approx.) 

1  Cable 

3  Cables 

7  Cables 

12  Cables 

22 

15 

12 

9 

9 

16 

33 

28 

26 

25 

10 

110 

107 

104 

101 

4 .9. 5. 3  Power  Monitoring.  It  was  recognized  that  some  method  of 
determining  battery  discharge  levels  would  be  required  during  experiments.  This  require¬ 
ment  was  necessitated  by  the  need  to  ensure  the  controlled  termination  of  maneuvering 
prior  to  battery  power  falling  below  acceptable  minimums.  Premature  shutdown  due  to 
inadequate  power  margins  could  prove  catastrophic;  the  loss  of  motor  torque  might  result 
in  the  uncontrolled  dumping  of  system  momentum,  thereby  manifesting  itself  in  uncon- 


4-94 


trolled  angular  accelerations  imparted  to  the  satellite.  For  this  reason,  hardware  to  monitor 
available  power  was  deemed  a  requirement. 

One  possible  method  of  implementing  power  monitoring  capabilities  would  rely  upon 
the  data  collection  and  telemetry  subsystem  already  onboard  SIMS  AT.  Voltage  and  cur¬ 
rent  (across  each  of  the  batteries  individually,  or  collectively)  could  be  monitored  using 
voltmeters  and  ammeters.  Telemetry  from  these  sensors  would  be  collected  using  data 
input  channels  routed  to  AutoBox,  which  in  turn  would  transmit  the  telemetry  stream  to 
the  ground  station.  Outputs  from  these  channels  would  be  displayed  for  the  experimenter. 
Although  attractive  in  some  respects,  this  method  was  not  chosen  for  baseline  system  im¬ 
plementation.  Concerns  centered  on  system  complexity,  particularly  with  regard  to  the 
issue  of  data  dropout  during  an  experiment.  This  scheme  also  requires  the  allotment 
of  AutoBox  input  channels,  decreasing  the  available  channels  for  an  experimenter/ user. 
Although  battery  telemetry  remains  a  possibility  for  future  system  implementation,  this 
option  was  not  incorporated  in  the  baseline  SIMSAT  design. 

In  lieu  of  battery  telemetry,  which  resembles  current  satellite  monitoring  practices, 
a  more  prosaic  option  was  selected.  This  system  takes  advantage  of  the  fact  that  the 
satellite  is  not  remotely  located,  but  instead  is  in  close  proximity  to  the  user.  A  voltage 
monitoring  relay  in  series  with  a  sonoalarm  (audible  tone  buzzer)  provides  a  direct  indi¬ 
cation  of  system  voltage  falling  below  a  specified  level.  Since  the  operating  characteristic 
curve  of  a  Power-Sonic  PS-12180  is  specified  with  reasonable  certainty  (from  manufacturer 
specifications),  a  drop-out  voltage  can  be  selected  corresponding  to  an  acceptable  power 
margin  for  immediate  system  shutdown.  This  electromechanical  system  would  provide 
a  straightforward  approach  to  achieving  the  desired  end  result,  while  minimizing  system 
hardware  and  integration  impacts. 

Catalog  searches  indicated  that  the  Macromatic  VMP024D  voltage  monitoring  relay 
was  suited  to  meet  system  requirements.  This  part  was  commercially  available  with  min¬ 
imum  time  delay.  Voltage  monitoring  relays  are  not  commonly  found  for  voltages,  around 
36V  since  this  operating  voltage  is  not  typical  for  most  applications.  24V  systems,  by 
comparison,  are  more  common;  therefore,  the  VMP024D  was  designed  around  a  nominal 
24V.  Because  of  this  constraint,  the  VMP024D  was  integrated  to  measure  the  voltage 
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drop  across  only  two  of  the  three  onboard  batteries.  This  voltage  allows  a  proxy  measure 
for  the  total  system  voltage,  since  the  discharge  across  any  one  battery  should  remain 
fairly  close  to  that  of  the  other  two.  Since  some  batteries  are  “loaded”  more  heavily  than 
others,  however,  the  relay  was  wired  across  the  two  most  heavily  loaded  batteries  to  en¬ 
sure  a  conservative  reading.  Based  upon  characteristic  curves  for  Power-Sonic  batteries, 
a  lowest  allowable  discharge  voltage  of  11.6V  (for  each  battery)  was  desired.  This  voltage 
corresponds  to  a  remaining  battery  capacity  of  approximately  10%.  The  VMP024D  relay 
can  be  ordered  with  a  pick-up  voltage  between  21-27V.  The  relay  de-energizes  when  the 
monitored  voltage  is  below  the  drop-out  setting,  set  at  3%  below  the  pick-up  voltage.  A 
VMP024D  relay  with  pick-up  voltage  set  at  24V  would  drop  out  near  23.3V,  or  11.6V  over 
each  of  two  batteries;  therefore,  this  setting  was  specified  for  purchase. 

4- 9. 5. 4  Bus  Modularity.  A  major  objective  of  the  SIMS  AT  design 
effort  was  to  maximize  system  modularity  to  the  greatest  extent  possible.  Modularity, 
particularly  at  the  payload  interface  level,  provides  the  experimenter  with  the  most  flex¬ 
ibility  in  obtaining  the  desired  data  set.  From  a  power  perspective,  the  decision  to  use 
12V  batteries  allowed  for  the  consideration  of  multiple  power  “buses” ,  offering  standard 
connections  to  12,  24,  and  36V  DC  supplies.  Because  of  structural  design  constraints,  how¬ 
ever,  implementation  of  all  three  buses  on  both  sides  of  the  truss  presented  some  wiring 
challenges.  Equipment  separation  (i.e.,  placement  of  hardware  on  both  sides  of  the  central 
sphere)  implied  the  need  for  power  cabling  through  the  hollow  center  of  the  air-bearing 
assembly,  as  shown  in  Figure  4.29.  Minimizing  the  amount  of  power  cabling  was  highly 
desired,  since  the  total  volume  available  for  all  types  of  cable  (power,  communications,  air, 
etc.)  was  limited.  Although  power  from  the  36V  supply  line  could  be  easily  tapped  on 
both  sides  of  the  system,  availability  of  24V  power  was  constrained  by  the  arrangement  of 
batteries  onboard  (see  Figure  4.29).  A  decision  to  require  24V  power  connections  on  the 
experiment  side  of  the  truss  required  two  extra  cables  run  through  the  central  sphere  (a 
total  of  6  wires  compared  to  the  minimum  of  4).  12V  power  could  be  readily  provided  on 
both  sides  of  the  satellite,  however,  since  at  least  one  battery  is  present  on  either  side  of  the 
air-bearing  assembly.  Further  inputs  from  the  decision  makers  were  required  to  determine 
the  payload  power  interfaces. 
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Experiment  Side 


Wheel  Side 


4-9. 5. 5  Power  Interfaces.  Discussions  with  the  decision  makers  iden¬ 
tified  their  preferences  in  considering  power  connections  to  experimental  payloads.  The 
following  characteristics  were  listed  as  important  when  designing  the  payload/component 
power  interfaces: 

•  12V/24V/36V  bus  capability  required  on  both  sides  of  the  satellite. 

•  Power  and  data  cable  connections  should  be  physically  different  to  prevent  improper 
connection. 

•  Positive  latch  mechanism  required  to  ensure  good  physical  connection  is  established 
and  maintained. 

•  Single  multi-pin  plug  with  all  three  bus  voltages  should  be  available,  or  three  separate 
plugs  (one  each  for  12V,  24V,  and  36V)  providing  a  “single  face”  to  the  experimenter 
(multi-pin  plug  is  preferred). 

•  In  addition  to  supporting  experimental  hardware  connections,  components  should  be 
designed  to  interface  with  the  appropriate  voltage  bus  where  possible,  rather  than 
directly  hardwiring  them  to  the  battery  terminals. 

•  Fiber-optic  cable  attachments  were  not  deemed  necessary  for  baseline  system  imple¬ 
mentation. 

Based  upon  these  inputs,  the  original  wiring  diagram  was  modified  to  indicate  the 
use  of  bus  terminals  as  wiring  junctions,  as  shown  in  Figure  4.30.  Location  of  the  buses 
was  determined  based  upon  the  updated  physical  layout.  On  the  payload  side  of  SIMS  AT, 
the  bus  bars  were  mounted  on  the  reverse  side  of  the  gyro/battery/transceiver  mounting 
plate,  while  on  the  momentum  wheel  side  the  buses  were  located  on  the  reverse  side  of  the 
primary  battery  mounting  plate.  Due  to  the  heavy  wire  required  between  the  batteries  and 
amplifiers,  these  connections  were  not  considered  appropriate  to  place  on  the  36V  bus.  All 
other  items  (including  all  12V  and  24V  connections)  were  deemed  appropriate  for  inclusion 
on  their  respective  buses.  Additionally,  a  multi-strand  power  connector  cable  running  from 
all  three  payload-side  buses  to  the  payload  plate  was  required.  The  use  of  18-gauge  wire  in 
the  power  connector  cable  allowed  for  power  outputs  of  up  to  60W,  120W,  and  180W,  for 
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experiments  running  at  12V,  24V,  and  36V,  respectively.  A  power  connection  cable  was 
not  included  for  the  momentum  wheel  side  in  the  baseline  design,  due  to  no  foreseen  need 
for  such  capability  at  this  time  (as  decided  by  the  decision  makers).  Should  the  need  arise 
to  provide  power  to  momentum  wheel-side  experimental  payloads,  power  connections  from 
the  momentum-wheel  side  buses  could  be  implemented  with  relatively  little  effort. 


Figure  4.30  Modified  Wiring  Diagram 

4- 9. 5. 6  Electrical  Grounding.  Grounding  (more  generally,  prevention 
of  excessive  static  charge  buildup)  remains  an  issue  subject  to  further  design  work  as  sys¬ 
tem  integration  and  initial  testing  warrants.  Because  the  air-bearing  is  a  Teflon  sphere 
physically  separated  from  the  pedestal  on  a  cushion  of  air,  it  is  very  possible  that  the 
satellite  will  remain  electrically  isolated  from  its  surroundings.  The  presence  of  rotat¬ 
ing  electromechanical  devices  (i.e.,  the  momentum  wheels  and  their  associated  motors) 
presents  an  opportunity  for  static  charge  creation  and  buildup  on  the  surface.  Even  if  this 
charge  is  not  sufficient  to  present  a  safety  hazard  to  laboratory  personnel,  the  possibility  of 
uncontrolled  discharge  or  arcing  presents  the  possibility  for  damage  to  sensitive  electronic 
components.  At  this  time,  the  problem  of  static  charging  has  not  been  defined  in  quantifi- 
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able  terms.  Possible  methods  for  mitigation  may  include  static  discharge  probes  mounted 
to  SIMSAT  in  a  manner  similar  to  modern  aircraft.  Alternatively,  periodic  discharging 
using  a  brush  or  pole  mechanism  operated  manually  or  automatically  may  be  required. 
Finally,  if  the  problem  proves  severe  enough,  a  permanent  grounding  wire  may  need  to  be 
attached  to  satellite  connecting  it  to  “earth”  ground.  This  solution  would  not  only  impede 
free  motion  of  the  satellite,  but  it  would  also  add  a  permanent  (albeit  small)  disturbance 
torque  to  the  simulator  which  would  need  to  be  countered. 

4-9.5. 7  RFI/EMI  Interference.  Another  related  electrical  issue  was 
the  possibility  of  radio  frequency/electromagnetic  interference  (RFI/EMI)  created  by  SIM¬ 
SAT  subsystems.  The  momentum  wheel  motors  pose  the  greatest  potential  source  of  inter¬ 
ference  within  the  simulator,  since  rotating  machinery  is  notorious  for  creating  electrical 
noise.  Additionally,  the  mere  presence  of  passing  electric  current  through  wiring  implies 
the  creation  of  an  antenna,  with  the  potential  of  creating  undesirable  RFI.  Use  of  wireless 
communications  may  provide  some  concern,  as  well.  Again,  the  RFI  issue  has  not  been  de¬ 
fined  in  quantifiable  terms.  It  was  hoped  that  experience  gained  during  initial  integration 
efforts  would  result  in  scoping  of  the  problem  and  its  overall  relative  importance.  Potential 
mitigation  techniques  include  shielding  of  cables  and  individual  components,  movement  of 
components  to  induce  shadowing  effects,  or  line  filters.  Additionally,  the  use  of  optical 
signals  (rather  than  electrical  signals)  would  completely  avoid  the  RFI  issue,  at  least  with 
regard  to  some  channels  (particularly  data  collection).  Fiber  optic  cable  assemblies  can 
be  purchased  commercially  in  standard  lengths  with  standard  end  connectors.  However, 
system  complexity  and  cost  would  be  substantially  increased. 

4-9.6  Communications  Architecture.  Development  of  the  communi¬ 
cations  architecture  was  an  ongoing  design  process,  which  required  modifications  as  sub¬ 
system  components  were  selected  and  altered.  For  the  most  part,  communications  archi¬ 
tecture  decisions  were  driven  by  signal  requirements  of  the  various  components.  As  the 
full  integration  of  components  was  not  possible  as  this  document  went  to  print,  detailed 
signal  requirements  were  left  unspecified,  but  a  general  communications  architecture  was 
developed  such  that  integration  of  components  would  be  easily  facilitated. 
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4* 9. 6.1  Payload  Signal  Interface  Design.  A  primary  driver  in  the 
overall  communications  architecture  concerned  the  interface  with  the  experimental  pay- 
load.  As  a  testbed  for  experimental  research,  a  well-defined  and  easily  adaptable  com¬ 
munications  interface  was  required  to  ensure  adequate  input/output  data  channels  for 
experiment  telemetry  and  command  data.  Signal  interface  design  was  initiated  with  an 
estimation  of  baseline  system  channel  requirements.  The  dSPACE/AutoBox  C&DH  ar¬ 
chitecture  provided  up  to  32  input  and  32  output  signals.  Internal  A/D  and  D/A  cards 
(DS2003  and  DS2103,  respectively)  allow  analog  voltage  signals  (±5V  or  ±10V)  to  interface 
with  the  dSPACE/AutoBox. 

No  telemetry  data  from  the  power  system  or  the  wireless  systems  was  anticipated, 
but  the  gyros  and  amplifiers  would  require  a  number  of  input  and  output  signals.  For 
the  Humphrey  gyro  system,  initial  signal  estimates  included  ten  inputs  from  the  gyros, 
with  four  outputs  to  the  gyros  (may  not  be  required  in  the  final  design).  These  estimates 
were  considered  conservative;  laboratory  evaluation  of  the  gyros  was  in  process  at  this 
stage  which  should  indicate  which  signals  were  required  and  which  were  not.  Similarly, 
six  input  and  six  output  channels  were  estimated  for  the  amplifiers.  This  estimate  allowed 
two  channels  per  motor.  Using  these  estimates,  16  input  channels  were  available  to  the 
experiment  payload.  Six  output  channels  were  reserved  for  thruster  integration.  The 
exact  number  of  signals  to  the  thrusters  was  not  known  at  this  time,  but  this  estimate  was 
considered  reasonable.  Thus,  16  output  channels  were  also  unused  by  the  baseline  system. 

Early  communications  architecture  design  stressed  full  signal  interface  modularity.  A 
proposed  architecture  included  a  full  32-input /32-output  (“32/32”)  interface  board  on  each 
side  of  the  central  sphere.  This  design  would  allow  complete  channel  availability  on  either 
side,  without  the  need  to  route  additional  wires  through  the  sphere  during  an  experiment. 
Basically,  the  design  would  incorporate  two  32-wire  lines  permanently  configured  through 
the  center,  with  a  full  32/32  interface  board  on  both  base  mounting  plates,  wherein  all 
input/output  connections  would  be  made.  The  32/32  interface  board  would  be  similar  to 
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that  used  with  the  ground-based  dSPACE  system31.  This  proposed  architecture  was  ex¬ 
panded  further  to  allow  full  32/32  channel  availability  at  each  mounting  plate,  wherein  each 
plate  would  be  connected  using  32-wire  lines  and  junction  boxes  would  allow  selection  of 
which  input /output  channels  were  active.  However,  this  architecture  was  considered  overly 
modular  since  in  no  foreseeable  instance  would  either  side  require  all  32  channels.  In  short, 
the  ADACS  and  payload  hardware  would  never  be  both  on  the  one  side  simultaneously. 
The  benefits  of  a  common  32-pin  (maximum)  connector  for  each  subsystem  interface  (with 
inactive  pins  removed  for  each  subsystem)  were  deemed  marginal  at  best.  This  alternative 
also  included  the  drawback  of  excess  cabling/junction  weight. 

Conversation  with  the  decision  makers  indicated  that  a  16-input  and  8-output  inter¬ 
face  would  meet  foreseeable  SIMS  AT  requirements  for  the  primary  payload  side.  For  the 
momentum  wheel  side,  an  8-input  and  4-output  capability  would  adequately  allow  mount¬ 
ing  of  payload  hardware  and  collection  of  data  on  that  side.  This  reduction  in  channel 
availability  allowed  savings  in  cabling  weight  and  wiring  complexity.  Several  interfacing 
techniques  were  considered.  The  preferred  design  included  4-channel  banks  which  would 
take  four  channel  signals  from  the  payload  and  bundle  them  into  one  wire.  Figure  4.31(a) 
shows  the  payload  input /output  interface  architecture  using  the  4-channel  banks.  This 
wire  would  be  permanently  routed  to  the  main  AutoBox  signal  interface  board  which 
would  be  plugged  into  the  AutoBox  using  32-pin  connectors,  as  shown  in  Figure  4.31(b). 
A  physical  constraint,  the  AutoBox  required  a  32-pin  connector  for  both  the  input  and 
output  channels.  This  design  allowed  a  reasonable  compromise  in  the  number  of  con¬ 
nection  wires  (minimum  preferred)  versus  the  number  of  available  channel  configurations 
(maximum  preferred)32.  Several  details  of  this  architecture  still  required  definition. 

Channel  Switching.  To  start,  not  all  channels  could  simultaneously 
be  used  at  once.  Only  16  total  inputs  were  available,  so  if  a  bank  of  four  channels  was 
being  used  on  the  momentum  wheel  side,  only  three  banks  of  four  would  be  available  on  the 

31  Rack-mounted  3 2-input /32-output  connection  panels  were  provided  with  the  dSPACE  system.  These 
panels  allow  the  development  of  a  ground-based  simulator  which  can  be  used  without  the  air-bearing 
assembly  and  satellite  power  system. 

32  For  example,  nine  input  channels  on  the  primary  payload  side  and  seven  input  channels  on  the  mo¬ 
mentum  wheel  side  would  not  be  a  feasible  configuration  using  4-channel  banks. 
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(b)  AutoBox  Channel  Interface  Board 

Figure  4.31  Signal  Interface  Architecture 
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primary  payload  side.  Activating  the  necessary  banks  required  either  a  switch  or  manually 
plugging  the  needed  bank  into  the  input/output  interface  board.  It  was  determined  that  a 
switch  would  entail  added  complexity  in  the  design  for  little  benefit.  It  would  be  almost  as 
easy  to  unplug  one  bank  and  plug  in  another.  Thus,  the  final  signal  interface  architecture 
required  the  experimenter  to  plug  in  the  active  channel  banks.  Three  cables  would  be 
permanently  routed  through  the  center  to  provide  the  momentum  wheel-side  banks.  At 
the  input/output  interface  board  (see  Figure  4.31(b)),  these  channel  bank  wires  would  be 
permanently  positioned,  allowing  active  banks  to  be  easily  plugged  in. 

Interface  Board  Placement.  The  channel  banks  would  be  mounted 
on  the  payload  interface  mounting  plates  along  with  the  power  interface  connections.  The 
input/output  interface  board  would  be  positioned  near  the  AutoBox,  allowing  a  very  short 
distance  between  the  board  and  the  AutoBox  32-pin  connectors.  Preferably,  the  interface 
board  would  be  mounted  on  one  of  the  AutoBox  mounting  plates. 

Wiring  Identification .  To  ensure  that  wires  are  clearly  defined, 
input  wires  would  have  black  connections  to  the  interface  board,  and  output  wires  could 
have  blue  connections.  This  color-coding  is  consistent  with  the  black/blue  32-wire  ribbon 
cables  used  on  the  rack-mounted  input/output  boards33.  Similarly,  black  and  blue  ribbon 
cables  could  be  used  for  the  onboard  AutoBox  connections.  To  identify  which  side  the  bank 
wires  connect  to,  all  momentum  wheel-side  (secondary  payload  interface)  banks  could  be 
marked  with  tape  (or  a  similar  marking). 

Baseline  Channel  Requirements.  The  architecture  allows  each 
subsystem  to  interface  to  the  AutoBox  interface  board  with  a  single  cable.  This  commu¬ 
nications  architecture  is  simple  enough  that  modifications  can  easily  be  made.  If  more  or 
less  channels  are  required  by  the  baseline  subsystems,  the  number  of  pins  used  in  their 
respective  connector  can  be  adjusted. 

33  Any  color-coding  protocol  would  suffice,  but  the  design  team  recommended  this  scheme. 
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4. 9. 6. 2  Momentum  Wheel  Integration.  Integration  of  the  momentum 
wheels  with  each  subsystem  was  a  phased  approach.  In  the  first  phase,  each  momentum 
wheel  was  successfully  mounted  on  the  motor  shaft.  A  primary  concern  during  this  phase 
was  designing  a  mechanism  to  prevent  disaster  if  the  motor  “locked  up”  during  an  experi¬ 
ment.  It  was  unknown  if  the  sudden  loss  of  power  to  the  motor  would  cause  the  momentum 
wheel  to  come  to  an  abrupt  halt.  Therefore,  to  prevent  total  momentum  transfer  to  the 
vehicle,  a  brass  shear  pin  was  inserted  through  the  axle  and  the  momentum  wheel’s  mount¬ 
ing  sleeve.  In  case  of  emergency,  the  brass  pin  would  break  and  allow  the  momentum  wheel 
to  spin  freely  until  it  came  to  rest.  This  would  still  transfer  momentum,  but  would  occur 
at  a  gradual,  not  instantaneous,  rate. 

Following  the  successful  mounting  of  the  momentum  wheel,  the  second  phase  was 
connecting  the  motor  with  the  amplifier  (amp).  From  a  signal  standpoint,  wheel  speed 
information  is  passed  from  the  motor  to  the  amp.  Control  inputs  are  sent  from  the  amp 
to  the  motor. 

On  2  February  1999,  an  amp  was  successfully  connected  to  a  momentum  wheel. 
Using  a  20VDC  power  supply,  the  momentum  wheel  achieved  a  top  speed  of  1050  RPM. 
This  speed  was  measured  using  a  timing  gun  provided  by  Mr.  Jay  Anderson. 

The  final  phase  (yet  to  be  accomplished  at  the  time  of  this  printing)  involves  the 
integration  of  the  amps  with  the  AutoBox. 

4. 9. 6. 3  Rate  Gyro  Integration.  Three  integration  issues  existed  for 
the  Humphrey  gyro.  First,  due  to  the  sensitivity  of  the  gyro,  it  was  imperative  that  it 
be  shock  mounted.  Natural  rubber  plate-form  mounts  from  the  McMaster-Carr  Supply 
Company  in  Cleveland,  OH,  were  ordered  to  be  used  to  isolate  the  gyro  components  from 
the  mounting  plate. 

Second,  the  gyro  has  to  be  integrated  with  the  AutoBox  to  send  SIMS  AT  rate  and 
acceleration  information.  The  output  signal  from  each  rate  gyro  and  accelerometer  is  a 
0-5V  analog  signal.  For  each  rate  gyro  and  accelerometer,  2.5V  represents  a  null  reading. 
Readings  above  2.5V  represent  a  clockwise  rotation.  Readings  below  2.5V  represent  a 
counterclockwise  movement. 
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This  signal  is  sent  to  the  AutoBox  and  is  converted  to  a  16-bit  digital  signal  through 
an  A/D  converter.  At  this  point,  the  Simulink  code  receives  the  digital  signal  as  the 
SIMS  AT  angular  velocities  and  accelerations  in  terms  of  voltage.  Using  a  calibration 
curve  developed  from  data  delivered  by  the  manufacturer,  the  input  voltage  is  converted 
to  deg/sec  or  deg/sec2  (see  Appendix  E  for  conversion  details).  The  output  of  these 
conversions  is  then  used  by  the  for  controlling  SIMS  AT  motion.  At  the  time  of  this 
printing,  laboratory  technicians  were  working  on  collecting  and  interpreting  these  gyro 
signals. 

The  last  integration  consideration  was  the  input  power  specification.  As  stated  be¬ 
fore,  the  gyro  uses  an  operating  voltage  of  28±V  DC. 

4. 9. 6.4  Wireless  LAN  Integration.  Due  to  schedule  constraints  and 
the  late  acquisition  of  the  wireless  LAN  system,  the  wireless  integration  was  delayed. 
Integration  procedures  are  described  in  this  section,  but  actual  integration  and  testing  of 
the  system  was  anticipated  to  begin  in  late  February  1999.  Integration  was  to  proceed  in 
several  steps,  described  by  the  following  paragraphs. 

ISA  CardLINK  Connection.  The  following  integration  tasks 
provide  a  brief  summary  of  the  ISA  CardLINK  installation  procedures.  Detailed  procedures 
are  described  in  the  user’s  guide  provided  with  the  ISA  CardLINK. 

•  Mount  the  transceiver  within  the  SIMS  AT  enclosed  laboratory  area. 

•  With  PC  power  removed,  install  the  Model  101c  adapter  card  using  an  available  ISA 
slot  in  the  Simulation  PC. 

•  Connect  the  transceiver  to  the  Model  101c  card  using  the  supplied  adapter  cable. 

•  Power  the  PC;  Windows  operating  system  will  detect  the  Model  101c  card  and 
prompt  for  software  installation. 

•  Insert  the  RadioLAN  Drivers  disk  and  install  the  driver  software. 
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DockLINK  Integration.  The  DockLINK  User  Guide  [44]  provides 
detailed  system  installation  procedures.  This  section  identifies  points  to  consider  during 
the  integration  of  the  DockLINK  system. 

First,  the  radio  transceiver  is  connected  to  the  DockLINK  using  the  supplied  DB15 
jack.  The  installation  procedures  indicate  that  the  transceiver  should  be  mounted  parallel 
to  the  ground  station  transceiver.  As  SIMS  AT  will  be  in  motion,  this  parallel  align¬ 
ment  is  not  possible.  Conversation  with  RadioLAN  technical  support  confirmed  that  in  a 
short-range  application  such  as  this  design,  a  rotating  transceiver  should  not  be  an  issue. 
However,  if  this  configuration  results  in  high  data  dropout,  the  system  should  be  returned 
to  RadioLAN. 

The  supplied  power  adapter  should  be  used  to  power  the  DockLINK  during  initial 
testing.  Once  initial  checkout  is  accomplished  and  the  power  architecture  is  developed,  use 
of  SIMS  AT  battery  power  can  be  used. 

The  DockLINK  R  J-45  jack  will  need  to  be  connected  to  the  AutoBox  using  a  lOBaseT 
Network  Interface  Card.  With  the  AutoBox  Ethernet  card,  this  connection  should  be 
provided  already34.  An  IP  address  is  assigned  to  the  DockLINK  using  procedures  described 
in  the  user  guide. 

4- 9. 6. 5  Wireless  Modem  Integration.  As  stated  in  Section  4.8.10, 
page  4-89,  the  wireless  modem  would  not  require  significant  integration  effort.  The  WIT2400E 
unit  includes  its  own  power  supply  and  connection  cabling,  and  it  is  small  enough  to  be 
mounted  nearly  anywhere  convenient.  Thus,  power  and  physical  integration  issues  were 
not  of  concern.  A  DB-25  data  connector  is  supplied  with  the  WIT2400  Developer’s  Kit. 

If  individual  signal  pin-out  information  is  required,  the  DWC  website  [14]  provides  all 
modem  signal  information.  Once  the  modem  is  delivered,  laboratory  technicians  would 
be  required  to  connect  the  wireless  modem  using  the  RS-232  interface  by  configuring  a 
suitable  connection  to  the  RS-422-A  high  density  sub-D  connector  of  the  AutoBox.  This 
connector  can  be  in-house  developed,  or  a  COTS  converter  can  be  purchased.  Black  Box 

34Wired  integration  of  the  AutoBox  to  the  Simulation  PC  was  successfully  accomplished.  The  wireless 
LAN  should  use  the  same  connections. 
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Corporation  produces  a  line  of  interface  converters,  to  include  RS-232  to  RS-422,  which 
may  be  used  once  wireless  modem  integration  is  underway  [6]. 

4-10  Safety  System  Design 

4  >10.1  Problem  Statement.  This  design  iteration  addressed  the  safety 
system  subproblem,  as  summarized  below: 

Investigate  the  safety  issues  associated  with  SIMSAT  operation,  and  recommend  a 
preferred  safety  system  (or  systems)  to  mitigate  the  risks  of  personnel  injury  and  equipment 
damage. 

4.10.2  Problem  Scope.  The  SIMSAT  system  was  to  be  operated  in  a 
laboratory  environment,  wherein  certain  safety  measures  were  desired  to  ensure  that  re¬ 
searchers,  students,  and  observers  could  safely  perform  and  monitor  simulator-based  ex¬ 
periments.  Furthermore,  the  high  costs  associated  with  this  project  made  the  reduction 
of  equipment  damage  due  to  mishaps  or  system  failures  a  necessity.  As  a  one-of-a-kind 
system,  any  significant  damage  to  the  SIMSAT  software  or  hardware  components  may 
result  in  extensive  research  program  setbacks.  Enhanced  safety  measures  would  better 
accommodate  sensitive  and  expensive  experimental  payloads  as  well,  thereby  encouraging 
more  research  and  experimentation  by  outside  agencies. 

In  order  to  provide  this  necessary  level  of  safety,  operational  risks  first  needed  to  be 
identified.  Based  on  these  risks,  techniques  and  mechanisms  were  formulated  to  minimize 
the  system  impacts  associated  with  these  risks.  These  safety  measures  were  analyzed  on 
a  system  level  to  allow  selection  of  a  preferred  safety  system  which  reduces  risk  while 
considering  system  impacts  with  respect  to  cost,  schedule,  and  performance. 

4.10.3  Safety  System  Background.  Throughout  the  SIMSAT  develop¬ 
ment,  the  importance  of  minimizing  operational  risks  was  recognized  as  fundamental  to 
system  design.  From  the  first  objective  hierarchy  of  the  Concept  Exploration  and  Definition 
phase,  personnel  injury  and  equipment  damage  were  addressed,  through  the  identification 
of  hazards  and  associated  hazard  severity  of  competing  system  architectures.  The  Pre- 
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liminary  Design  phase  included  estimations  of  relative  safety  indices  to  be  used  in  system 
evaluation  and  selection.  Moreover,  in  the  first  iteration  of  the  Detailed  Design  phase,  the 
need  to  contain  the  momentum  wheel  assembly  was  addressed  to  prevent  loose  objects  from 
projecting  off  a  rotating  momentum  wheel,  as  well  as  prevent  significant  damage  in  the 
event  of  a  catastrophic  motor  shaft  failure.  A  lexan  box  enclosure  about  the  momentum 
wheels  was  selected  to  satisfy  these  safety  concerns.  Other  safety  measures  considered  in 
the  Detailed  Design  phase  included  the  following: 

•  Anti-tipping  stanchion  braces  to  prevent  an  imbalanced  satellite  from  falling  off  the 
stanchion  supports  (while  being  configured). 

•  Incorporation  of  an  alarm  mechanism  to  detect  low  voltage  conditions,  thereby  warn¬ 
ing  an  experimenter  when  the  system  is  running  low  on  power. 

•  Use  of  a  padded  collar  about  the  air  bearing  pedestal,  minimizing  structural  damage 
to  the  satellite  and  pedestal  if  pitch  limits  are  exceeded. 

•  Consideration  of  safe  electrical  design,  to  include  grounding  of  the  satellite  to  prevent 
a  charge  buildup. 

At  this  stage,  however,  two  remaining  safety  issues  were  yet  to  be  examined  through 
formal  system  analysis.  This  design  subproblem  addressed  these  issues. 

4-10.4  Safety  Issues.  The  first  issue  of  concern  at  this  stage  of  the  design 
was  how  to  minimize  the  damage  should  the  satellite  topple  off  the  pedestal,  due  to  a 
structural  failure,  seized  motor,  physical  contact,  or  other  means.  Given  the  cost  of  the 
SIMS  A  T  hardware,  the  system  weight,  a  drop  distance  of  approximately  4  ft,  and  the  hard 
concrete  floor  of  the  lab  environment,  a  safety  system  was  deemed  necessary  to  safeguard 
against  the  catastrophic  loss  of  the  satellite  in  such  a  falling  accident.  The  second  issue 
was  related  to  the  emergency  shutdown  of  the  system,  which  was  an  identified  need  in  the 
Concept  Exploration  and  Definition  phase.  The  ability  to  prevent  system  damage  in  the 
event  of  a  communications  link  failure,  loss  of  power,  control  law  error,  or  other  emergency 
situation,  was  necessary  in  the  overall  system  design.  These  two  issues  were  interrelated 
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to  a  large  degree,  as  an  emergency  situation  could  potentially  induce  the  toppling  of  the 
satellite. 


4-10.5  Value  System,  Design.  The  following  prioritized  objectives  were 
used  in  the  evaluation  of  safety  mechanisms: 

•  Minimize  system  damage  (to  include  the  satellite  hardware,  the  air-bearing  cup,  the 
rotor,  and  the  pedestal)  in  the  event  of  an  emergency  shutdown  or  toppling  condition. 

•  Minimize  the  system  impacts,  in  terms  of  both  performance  and  structural  redesign, 
associated  with  the  safety  system  implementation. 

•  Minimize  environmental  impacts  due  to  implementation,  such  as  laboratory  con¬ 
struction  or  reconfiguration. 

•  To  the  maximum  extent  possible,  allow  system  accessibility  during  operation. 

•  Minimize  the  cost  and  schedule  of  the  safety  system  implementation. 

4.10.6  Safety  System  Alternatives  and  Selection.  Several  safety 
system  mechanisms  were  considered  throughout  the  SIMS  AT  development.  Each  of  these 
ideas  suffered  from  potential  drawbacks  in  addition  to  its  merits.  During  this  phase  of  de¬ 
sign,  these  potential  solutions  were  documented  and  analyzed,  as  described  by  the  following 
paragraphs.  A  recommended  safety  system  was  selected  for  implementation. 

4.10.6.1  Cargo  Net.  The  first  concept  examined  was  a  safety  net 
suspended  over  the  satellite  which  could  be  dropped  on  the  device  should  it  begin  to 
gyrate  in  an  unstable  or  uncontrollable  fashion,  as  shown  in  Figure  4.32  (figures  at  the 
end  of  this  section).  This  “cargo  net”  would  slow  down  SIMS  AT  as  the  device  became 
entangled  within  the  net.  Although  inexpensive  and  easy  to  implement,  this  device  would 
not  prevent  SIMS  AT  from  bouncing  out  of  the  air-bearing  pedestal  cup,  and  might  actually 
cause  such  a  mishap  depending  upon  the  situation.  Therefore,  the  cargo  net  option  might 
slow  down  a  tumbling  system,  but  it  could  not  protect  against  the  more  serious  threat  of 
SIMS  AT  falling  onto  the  laboratory  floor. 
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4-10.6.2  Lion  Trap.  The  next  concept  that  was  considered  had  the 
cargo  net  arrangement  reversed,  with  the  net  kept  on  the  floor  during  normal  operation. 
The  “lion  trap”  scheme,  shown  in  Figure  4.33,  involved  the  hoisting  of  shroud  lines  should 
SIMS  AT  begin  to  tumble  out  of  control.  The  cargo  net  would  effectively  ensnare  SIMS  AT 
as  it  was  being  hoisted  towards  the  ceiling,  thereby  preventing  it  from  falling  to  the  floor. 
The  lion  trap  option  suffered  from  at  least  three  problems.  First,  having  the  cargo  net  on 
the  floor  would  create  a  safety  hazard  during  day-to-day  operations  and  impede  access  to 
the  satellite  during  experiments.  Second,  the  positioning  of  shroud  lines  on  the  cargo  net 
presented  an  opportunity  for  interference  with  experimental  payloads  extending  from  the 
basic  structure.  Finally,  it  was  unclear  that  the  lion  trap  could  be  “sprung”  with  sufficient 
rapidity  to  prevent  SIMS  AT  from  hitting  the  floor  first.  During  operation,  an  individual 
would  be  required  to  standby  for  actuation  of  the  safety  system  at  all  times,  and  even  then, 
a  person  may  not  be  able  to  react  fast  enough  under  all  scenarios.  The  limitations  of  the 
lion  trap  scheme  suggested  any  safety  mechanism  would  need  to  work  without  operator 
intervention. 


4-10.6.3  Trampoline.  The  next  alternative  considered  was  the  so-called 
“trampoline”  consisting  of  a  net  suspended  above  the  floor  but  below  the  satellite.  Fig¬ 
ure  4.34  shows  this  arrangement.  The  trampoline  would  be  set  prior  to  the  beginning  of 
an  experiment.  Should  the  satellite  fall  off  the  air-bearing  pedestal,  the  trampoline  would 
prevent  contact  with  the  floor.  Again,  this  option  suffered  from  multiple  drawbacks.  The 
trampoline  would  prevent  direct  access  to  SIMS  AT  during  experiments.  Stanchions  used 
to  support  the  trampoline  would  also  be  cumbersome  and  potentially  interfere  with  lab¬ 
oratory  operations.  Furthermore,  ensuring  the  trampoline  is  taut  enough  to  keep  a  3001b 
object  from  overly  stretching  the  net  would  be  an  extremely  difficult  task.  A  hybrid  two- 
net  scheme  combining  the  characteristics  of  both  the  lion  trap  and  trampoline  mechanisms 
was  also  rejected  for  these  same  reasons. 

4.IO.6.4  Floor  Padding.  An  easy  and  relatively  inexpensive  option 
considered  was  the  use  of  thick  padding  placed  on  the  floor.  Athletic-use  mats,  such  as 
those  used  for  high  jump  or  pole  vault  landings,  are  built  to  safely  support  the  impact  of 
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persons,  and  thus  could  potentially  support  the  SIMS  AT  weight.  They  could  also  be  easily 
pushed  aside  to  provide  access  to  the  system  during  experimentation,  although  they  would 
be  bulky  and  somewhat  cumbersome.  The  primary  drawback  of  such  a  system  was  the 
level  of  shock  protection  to  sensitive  and  expensive  onboard  hardware.  Significant  system 
damage  was  still  anticipated  despite  the  use  of  such  mats.  The  mats  may  also  restrict 
pitch  limits  for  extended  payload  configurations. 

4-10.6.5  Catch  Arms.  The  placement  of  hydraulic-  or  pneumatic- 
actuated  arms  mounted  on  the  side  of  the  air-bearing  pedestal  could  be  used  to  engage  the 
satellite  and  prevent  it  from  falling  during  an  emergency  situation.  This  idea  is  illustrated 
in  Figure  4.35.  Upon  analysis,  this  system  would  have  severe  drawbacks.  Significant 
hardware  construction  would  be  required  for  the  pedestal-mounted  arms,  which  would  be 
needed  all  around  the  bearing  cup.  Activation  of  such  a  system  would  also  be  a  difficult 
technical  challenge.  The  act  of  engaging  SIMS  AT  with  the  arms  may  bounce  the  satellite 
anyway,  and  an  unbalanced  satellite  may  topple  off  the  arms  despite  engagement.  In 
addition,  the  arms  would  have  performance  penalties  as  the  pitch  limits  of  the  system 
would  be  further  constrained. 

4.IO.6.6  Skullcap.  This  last  proposal  appeared  to  address  the  fall- 
protection  issue  adequately,  while  offering  minimal  access  interference.  The  “skullcap” 
arrangement,  shown  in  Figure  4.36,  would  involve  an  articulating  arm  mounted  on  the 
wall  of  the  laboratory,  which  is  stored  out  of  the  way  when  not  in  use.  A  metal  pole  with 
a  padded  plate  on  the  end  would  be  attached  to  the  arm.  This  pole  would  be  lowered  over 
the  central  sphere  of  the  satellite  prior  to  the  start  of  an  experiment.  Should  the  satellite 
attempt  to  bounce  out  of  the  air-bearing  pedestal  cup,  the  skullcap  would  be  positioned  to 
prevent  the  bearing  from  moving  any  appreciable  distance.  With  the  addition  of  a  lowering 
mechanism,  the  skullcap  could  be  fully  lowered  onto  the  bearing  (increasing  friction)  should 
SIMS  AT  begin  to  tumble  out  of  control.  Because  the  skullcap  is  positioned  opposite  the 
air-bearing  cup,  no  impingement  of  pitch  limits  is  made.  Drawbacks  associated  with  this 
design  include  the  need  to  construct  the  support  structure  for  the  articulating  arm,  as  well 
as  a  lowering  mechanism  for  the  skullcap  itself.  The  physical  positioning  of  the  SIMS  AT 
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pedestal  made  the  wall  a  logical  choice  for  this  supporting  structure,  as  ducting  in  the 
laboratory  ceiling  and  a  lack  of  rafter  reinforcements  precluded  a  ceiling-mounted  device. 

Based  on  the  analysis  of  safety  alternatives,  the  skullcap  safety  mechanism  was  rec¬ 
ommended  for  implementation.  This  technically-feasible  design  provided  containment  of 
the  central  sphere  within  the  air-bearing  pedestal  cup,  while  offering  limited  access  restric¬ 
tions  with  no  performance  impediments. 

4*10.7  Emergency  Shutdown  Considerations.  Regarding  emergency 
shutdown  of  the  system,  several  scenarios  were  considered.  A  loss  of  system  control  due  to  a 
physical  phenomenon  (such  as  motor  seizure,  momentum  wheel  malfunction,  or  structural 
failure),  loss  of  power,  or  controller  malfunction  would  cause  limited  damage  with  the 
addition  of  the  skullcap  safety  mechanism.  The  skullcap  would  prevent  catastrophic  system 
damage  by  preventing  the  satellite  from  falling  out  of  the  air-bearing  cup,  but  minor 
damage  to  the  finely-machined  central  sphere  of  the  satellite  may  likely  occur.  Damage 
to  the  finely-machined  cup  would  be  possible  as  well.  Space  Electronics,  Inc.,  stated  that 
repair  of  the  cup  and  sphere  would  be  possible  should  significant  resurfacing  be  needed. 
With  the  reserve  compressor  air  and  the  padded  skullcap,  this  damage  should  not  be  overly 
extensive. 

Because  control  law  processing  occurs  onboard  the  satellite,  loss  of  communications 
between  the  ground  and  satellite  should  not  complicate  emergency  shutdown.  Loss  of  signal 
could  be  recognized,  and  a  predetermined  onboard  control  sequence  could  be  initiated  to 
return  the  satellite  to  a  preset  position.  This  feature  was  not  designed  in  the  baseline 
controller  model,  but  its  addition  would  not  be  difficult  should  the  need  for  such  control 
logic  be  identified. 

4.10.8  Implementation.  With  the  limited  baseline  design  schedule,  it  was 
not  possible  to  begin  implementation  of  the  skullcap  safety  system.  Detailed  design  and 
fabrication  of  this  system  is  recommended  for  follow-on  system  design.  .Operation  of  the 
SIMS  AT  could  still  be  accomplished  without  this  safety  mechanism,  but  risks  of  a  toppling 
satellite  should  be  understood  and  adequately  minimized. 
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Figure  4.33  The  “Lion  Trap”  Safety  System 


Figure  4.34  The  “Trampoline”  Safety  System 


Figure  4.35 


Support  Arms 
(engaged) 


The  “Catch  Arms”  Safety  System 
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Figure  4.36 


The  “Skullcap”  Safety  System 
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4-11  Thruster  Integration 


4.11.1  Problem  Statement.  The  following  problem  statement  summarizes 
the  thruster  integration  subproblem: 

Select  a  feasible  thruster  alternative  for  SIMSAT  use,  and  identify  the  associated 
integration  issues. 

4.11.2  Problem  Scope.  During  the  Preliminary  Design  phase,  it  was  de¬ 
cided  to  use  momentum  wheels  as  the  primary  means  of  SIMSAT  attitude  control  with  the 
ability  to  add  cold-gas  thrusters  at  a  later  date.  This  approach  fit  well  with  the  primary  re¬ 
search  areas  planned  for  initial  SIMSAT  experiments,  while  allowing  additional  capability 
and  flexibility  for  follow-on  work  to  be  added  in  a  timely  fashion.  Although  thrusters  would 
not  be  present  in  the  baseline  design,  the  basic  bus  configuration  would  need  to  be  com¬ 
patible  with  future  thruster  implementation.  Therefore,  thrusters  were  actively  researched 
during  the  Preliminary  Design  phase  to  ensure  that  their  implementation  would  not  pose 
insurmountable  integration  issues  with  the  primary  attitude  control  system.  Discussions 
with  cold-gas  thruster  manufacturers  indicated  that  the  cost  of  a  complete  system  would 
be  in  the  neighborhood  of  $25,000;  therefore,  a  decision  was  made  to  only  incorporate 
thruster  compatibility  into  the  baseline  design.  Implementation  would  be  delayed  until 
that  time  in  the  future  when  sufficient  funding  became  available.  To  ensure  compatibility, 
a  baseline  thruster  system  needed  to  be  investigated,  to  include  thrusters  and  gas  bottles. 

4.11.3  Value  System  Design.  In  the  consideration  of  thruster  system 
alternatives,  the  following  prioritized  evaluation  considerations  were  identified: 

•  Minimize  structural  redesign  necessary  to  integrate  thrusters,  gas  bottles,  and  asso¬ 
ciated  distribution/regulation  equipment. 

•  Minimize  weight  and  inertia  penalties. 

•  Maximize  integration  ease  with  respect  to  signal  and  power  interfaces. 

•  Minimize  system  costs. 
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4-11.4  Thruster  Selection.  A  survey  of  companies  producing  cold-gas  jet 
thrusters  indicated  that  the  product  line  developed  by  Moog,  Inc.,  of  East  Aurora,  NY, 
would  satisfy  SIMS  AT  design  requirements.  Moog  is  a  worldwide  supplier  of  precision 
fluid  and  motion  control  products  and  systems  for  aerospace  and  industrial  applications. 
Founded  in  1951,  Moog  cold-gas  jet  products  have  been  used  on  a  variety  of  aerospace  ve¬ 
hicles,  including  GBI/EKV,  THAAD,  AS  AT,  and  the  Shuttle  EMU  SAFER  backpack.  For 
this  design,  the  Model  50-820  cold-gas  thruster  triad  was  chosen  as  the  most  likely  choice 
for  eventual  system  integration.  The  Model  50-820  is  a  member  of  a  family  of  commercial 
solenoid  cold-gas  thruster  valves.  In  particular,  the  Model  50-820  was  designed  and  quali¬ 
fied  for  the  Pegasus  XL  launch  vehicle  attitude  control  system.  The  triad  configuration  is 
a  neat  and  efficient  solution  for  packing  three  thrusters  into  a  very  small  volume,  while  al¬ 
lowing  for  three-axis  control  authority.  Additionally,  the  Model  50-820  minimizes  the  total 
number  of  integration  interfaces  to  other  SIMS  A  T  subsystems.  Physical  and  performance 
specifications  for  the  Model  50-820  are  listed  in  Table  4.14  [39].  Figures  4.37  and  4.38  show 
a  schematic  and  photographic  representation  of  the  Model  50-820,  respectively. 


Table  4.14  Thruster  (Moog  Model  50-820)  Specifications  [39] 


Operating  Pressure 

200-2500  psig  (13.7-172.4  bar) 

Proof  Pressure 

3750  psig  (258.4  bar) 

Burst  Pressure 

6250  psig  (431  bar) 

Atmospheric  Thrust 

252N;  1105N  (2000  psia  tank  pressure) 

Operating  Voltage  Range 

24-34V  DC 

Response  Time  (Open/Close) 

<  10ms 

Power  Consumption 

6-12W 

Leakage  (Internal) 

<  lOscc/min  per  seat 

Leakage  (External) 

<  30scc/min  for  entire  module 

Cycle  Life 

>  6000 

Weight 

0.951b  (0.43kg) 

Thermal  Capacity  (Operating) 

0-120  deg.  F 

Wetted  Materials 

Aluminum,  Stainless  Steel,  Vespel 

4.11.5  Thruster  Interfaces.  The  Model  50-820  uses  a  MS3476L10-6SN 
straight-plug  connector  with  backshell  strain  relief  per  M85049/52-10  [11].  The  inlet  port 
on  the  manifold  is  a  3/8”  outer  diameter  tube  with  a  9/16-18  thread.  The  port  is  per 
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Figure  4.37  Moog  Model  50-820  Schematic  [39] 


MS33649-06,  with  the  thread  listed  as  0.5625-18UNJF-3B.  Particulate  filtration  is  specified 
between  10-25  microns. 

Although  the  Model  50-820  was  designed  to  operate  using  gaseous  nitrogen,  discus¬ 
sions  with  Moog  engineers  indicated  that  dry  air  can  be  successfully  used  instead.  The 
use  of  dry  filtered  air,  readily  available  within  the  AFIT  laboratories,  would  substantially 
reduce  the  cost  of  operation  of  the  cold-gas  thruster  subsystem.  Discussions  with  Gas  Dry¬ 
ing,  Inc.,  manufacturer  of  the  air  compressor  used  by  AFIT/ENY,  indicated  the  current 
unit  is  capable  of  achieving  2400  psi  pressures  and  128  ppm  water  vapor  content  [24].  Ac¬ 
cording  to  Moog  engineers,  this  level  of  purity  should  be  adequate  for  use  with  the  Model 
50-820  and  should  pose  no  problems. 

The  Model  50-820  was  designed  to  operate  at  DC  voltages  between  24-34V.  This 
parameter  is  consistent  with  the  28V  bus  standard  used  in  many  aerospace  applications. 
This  factor  limited,  however,  the  choice  of  operating  voltage  available  on  the  main  SIMS  AT 
electrical  bus.  Only  24  V  and  36  V  main  bus  voltages  were  evaluated  for  use  on  SIMS  AT 
subsequent  to  the  recognition  of  this  limitation,  as  described  in  the  first  iteration  of  Detailed 
Design.  Additionally,  a  24V  bus  was  rated  only  marginally  adequate  to  support  the  Model 
50-820;  an  additional  voltage  source  would  most  likely  be  needed  to  ensure  reliable  and 
consistent  thruster  performance.  These  considerations  were  evaluated  at  the  system  level 
during  the  first  iteration  of  the  Detailed  Design  phase. 

The  thrusters  posed  no  significant  signal  integration  issues  at  this  stage.  Once 
thrusters  are  purchased  and  implemented,  the  required  signals  could  be  sent  using  some 
of  the  dSPACE  channels  allotted  to  the  experimental  payload. 

4-11 ‘6  Initial  Gas  Bottle  Sizing.  To  ensure  that  thrusters  could  be  easily 
retrofitted  to  SIMSAT,  a  decision  was  made  to  allow  for  placement  of  high-pressure  gas 
bottles  within  the  structural  envelope  of  the  baseline  design.  Since  gas  bottles  represent  the 
largest  volumetric  element  of  the  thruster  subsystem,  these  items  must  be  fully  accounted 
for  when  considering  placement  of  system  components.  Additionally,  location  of  the  gas 
bottles  relative  to  the  thruster  assemblies  (located  on  the  exterior  of  the  structure)  drives 
additional  considerations  such  as  piping  and  power  cable  routing.  From  the  outset,  it  was 
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assumed  that  thrusters  would  be  located  on  both  sides  of  the  air  bearing  to  ensure  full 
three-axis  control  with  single  redimdancy.  To  eliminate  the  need  for  high-pressure  piping 
routed  through  the  center  of  the  bearing  (which  is  constrained  by  signal  and  power  cables), 
a  two-bottle  architecture  was  chosen,  with  one  bottle  on  each  side  of  the  SIMS  AT  structure 
and  attached  to  the  respective  thruster  assembly. 

For  initial  sizing  of  the  gas  bottles,  a  baseline  case  was  developed  to  estimate  how 
much  expelled  mass  was  required  to  meet  performance  needs.  The  required  propellant 
mass  for  spin-up  or  spin-down  is  given  by  the  following  formula  where  W  is  the  required 
propellant  mass  (kg),  I  is  the  total  spin  impulse  (Ns),  g  is  the  acceleration  constant  (m/ s2), 
and  Isp  is  the  thruster  specific  impulse  (sec): 


W  =  I/(g-Isp) 

Using  a  baseline  value  for  I  of  300  Ns  (equating  to  a  final  spin  velocity  of  10  rad/s)  and 
an  Isp  of  50  sec,  the  expelled  mass  required  to  complete  a  maneuver  is  0.6  kg.  This  mass 
was  compared  against  the  tank  capacity  of  commercially  available  gas  bottles  to  determine 
which  products  might  be  suitable  for  this  application.  Three  candidate  bottles  were  found: 
the  Air  Products  &  Chemicals  Dl-  and  4X-series  high-pressure  bottles,  and  the  SpecAir 
Specialty  Gases  Enviro-Cyl  Model  C-10.  Specifications  for  these  three  products  are  listed 
in  Table  4.15,  using  manufacturer-provided  data. 


Table  4.15  Gas  Bottle  Specifications 


Alternative 

D  1-Series 

4X-Series 

Model  C-10 

Mass  (kg) 

7 

1.6 

1.8 

Height  (cm)  [w/o  valve] 

41 

26 

26 

Diameter  (cm) 

18 

10 

8 

Internal  Volume  (1) 

5.9 

1.6 

1.0 

Usable  Capacity  (kg) 

0.69 

0.14 

0.12 

Impulse  (Ns) 

338 

69 

59 

Bottle  Cost  ($) 

144 

280 

92 

Regulator  Cost  ($) 

360 

360 

110 
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4.11.7  Gas  Bottle  Selection.  It  was  quickly  determined  that  the  D1 
bottle,  the  only  candidate  with  a  usable  capacity  of  greater  than  0.6  kg,  was  too  large  and 
heavy  for  SIMS  AT  integration.  Therefore,  a  decision  was  made  to  relax  the  performance 
specifications  and  consider  only  the  4X  and  C-10  bottles.  Discussions  with  the  decision 
makers  indicated  that  an  angular  velocity  change  capability  of  2  rad/s  was  acceptable 
for  thruster  subsystem  implementation.  Both  the  4X  and  C-10  bottles  were  capable  of 
meeting  this  requirement.  The  use  of  two  gas  bottles  on  SIMS  AT  would  allow  a  total  AV 
of  4  rad/s,  or  the  ability  to  completely  spin-up  and  spin-down  2  rad/s  in  a  single  maneuver. 

Using  the  3D  Studio  VIZ  solid  modeling  software,  both  the  4X  and  C-10  gas  bot¬ 
tles  were  examined  for  integration  issues  related  to  the  overall  structural  design.  Bottle 
placement  and  fit  were  checked  out  relative  to  other  components.  Bottles  could  be  ade¬ 
quately  positioned  outside  the  main  baseline  components,  minimizing  potential  plumbing 
and  wiring  difficulties.  Based  on  the  fact  that  thrusters  would  not  be  implemented  during 
the  baseline  design  phase,  the  decision  makers  delayed  the  choice  between  the  4X  and  C- 
10  bottles  until  that  time  when  thrusters  will  be  implemented.  Minor  differences  in  tank 
capacity,  cost,  mass,  size,  and  regulator  performance  indicated  that  a  further  trade  study 
would  aid  in  choosing  between  the  4X  and  C-10  bottles  at  a  later  date. 

4.12  Detailed  Design  Summary 

In  this  phase,  the  broad  subsystem  solution  classes  of  the  Preliminary  Design  phase 
were  narrowed  and  system-level  issues  were  analyzed  in  detail.  The  first  iteration  of  this 
phase  resulted  in  a  detailed  system  architecture  to  facilitate  the  structural  design,  simula¬ 
tion  development,  interface  identification,  and  performance  estimation.  Prom  this  architec¬ 
ture,  subproblems  were  addressed  using  the  systems  approach  to  ensure  that  the  important 
system-level  concerns  were  considered.  All  subsystem  components  were  selected,  and  a  gen¬ 
eral  integration  strategy  was  formulated.  The  next  lifecycle  phase,  Final  Design,  addressed 
the  description  and  operation  of  the  resulting  SIMS  AT  design.  Unresolved  design  issues 
were  documented  and  future  design  activities  were  identified  in  the  Final  Design  phase. 
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V.  Final  Design 


5.1  Overview 

In  this  chapter,  final  SIMS  AT  design  specifications  are  described  in  detail.  Design 
conclusions  are  presented,  as  well  as  discussion  of  unresolved  design  and  integration  issues. 
In  addition,  areas  for  further  research  and  design  are  recommended. 

Integration,  fabrication,  and  full  testing  of  the  SIMS  AT  system  were  not  completed  at 
the  time  this  document  went  to  print.  Following  the  delivery  and  integration  of  subsystem 
components,  system  assembly  and  testing  will  begin.  A  detailed  user’s  manual  providing 
a  more  complete  description  of  the  system  and  operational  procedures  will  be  created  as 
a  stand-alone  guide  for  future  reference. 


5.2  Subsystem  Components 

This  section  describes  the  major  hardware  and  software  components  of  the  SIMSAT 
system  for  future  reference. 

5.2.1  Attitude  Determination.  The  Humphrey  CF75  Series  Axis  rate 
gyro  subsystem  provides  rate  sensor  capability,  including  accelerometers,  for  SIMSAT  at¬ 
titude  determination  functions.  The  manufacturer-provided  gyro  characteristics  are  listed 
in  Table  5.1. 

5.2.2  Attitude  Control.  For  satellite  attitude  control,  the  SIMSA T  system 
uses  three  momentum  wheels,  one  for  each  axis,  each  driven  by  a  dedicated  motor  and 
amplifier  assembly.  SIMSAT  is  also  designed  for  compatibility  with  cold-gas  thruster  atti¬ 
tude  control  systems.  The  controller  onboard  the  satellite  incorporates  rate  gyro  feedback 
to  provide  the  required  control  law  logic  needed  to  maintain  system  stability  and  execute 
commands  for  three-axis  active  control. 

5. 2.2.1  Momentum  Wheels.  The  momentum  wheels  were  manufac¬ 
tured  in-house  by  the  AFIT  fabrication  shop.  Each  wheel  is  comprised  of  a  steel  rim 
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Table  5.1  Humphrey  CF75  Characteristics 


Parameter 

Value 

Operating  Voltage 

28±4V 

Operating  Current 

0.58A 

Weight 

1.05  kg 

Roll  Rate  Range 

±120  deg/sec 

Roll  Accuracy  (Half  Range) 

1.2  deg/sec 

Roll  Accuracy  (Full  Range) 

4.8  deg/sec 

Pitch/Yaw  Rate  Range 

±40  deg/sec 

Pitch/ Yaw  Accuracy  (Half  Range) 

0.6  deg/sec 

Pitch/Yaw  Accuracy  (Full  Range) 

2.4  deg/sec 

affixed  to  a  thin  aluminum  disk,  with  an  outside  diameter  of  8.625”.  The  Animatics  BL- 
3450  brushless  DC  servo  motor  and  Advanced  Motion  Control  amplifier  model  BE40A8 
provide  momentum  wheel  control.  Motor  and  amp  characteristics  are  listed  in  Tables  5.2 
and  5.3.  Figure  5.1  shows  a  bench  test  using  the  momentum  wheel  attached  to  the  BL-3450 
motor,  and  connected  to  the  amplifier. 

Table  5.2  Animatics  BL-3450  Motor  Characteristics  [51] 


Parameter 

Value 

Peak  Torque 

750  oz-in 

Continuous  Torque 

250  oz-in 

Voltage  Constant 

13.7V /kRPM 

No  Load  Speed 

3398  RPM 

Torque  Constant 

18.5  oz-in/ Amp 

Rotor  Inertia 

0.025  oz-in-sec2 

Weight 

3.27  kg 

Number  of  Poles 

4 

Number  of  Slots 

24 

Length 

6.088  in 
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Table  5.3  Advanced  Motion  Control  Amplifier  Characteristics  [51] 


Parameter 

Value 

DC  Supply  Voltage 

20-80V 

Peak  Current 

±40A 

Max.  Continuous  Current 

±20A 

Switching  Frequency 

22±15  KHz% 

Bandwidth 

2.5  KHz 

Figure  5.1  Momentum  Wheel,  Motor,  and  Amplifier 


5. 2. 2.2  Baseline  Command  and  Control  Software.  The  following 
Simulink  files  are  stored  on  the  ground  station  PC  for  modeling  and  control  of  the  baseline 
SIMSAT  system;  these  files  accommodate  passive  experimental  payloads  as  well. 
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•  SIMSAT  Block  Library  (SSMlib.mdl):  This  backup  file  contains  SIMSAT  command 
and  control  software  blocks.  It  provides  a  source  of  existing  SlMULlNK  code  blocks 
for  future  users,  in  addition  to  the  application  software. 

•  Simulation  Code  ( SIMSAT  lT.mdl):  This  code  includes  a  plant  model  based  on 
SIMSAT  equations  of  motion.  It  is  designed  for  simulations  of  SIMSAT  dynamics 
to  test  new  control  laws,  command  and  display  capabilities,  and  dSPACE  integra¬ 
tion.  (Refer  to  Section  4.5,  Command  and  Control  Architecture  Design,  for  more 
information.) 

•  Real-Time,  Onboard  Code  ( SIMSAT  IB.mdl):  This  code  is  for  use  during  actual 
SIMSAT  operations.  It  contains  the  same  controller  and  input/output  links  as  the 
simulation  code,  but  is  integrated  with  the  dSPACE  hardware  on  AutoBox.  Fig¬ 
ure  5.2  illustrates  the  top-level  software  architecture  of  this  code. 

Payloads  utilizing  the  AutoBox  for  command  and  control  may  require  integration 
into  the  baseline  software  architecture.  This  may  necessitate  minor  changes  to  the  existing 
code,  or  major  additions  and  alterations. 

Any  experiment  added  to  the  baseline  SIMSAT ,  even  passive  ones,  will  change  the 
inertia  of  the  system.  Thus,  the  user  is  required  to  enter  new  inertia  values  in  the  Equations 
of  Motion  of  the  baseline  system1.  Off-line  simulations  can  then  be  used  to  generate  any 
necessary  changes  to  the  feedback  gains  for  proper  control.  These  new  parameters  should 
be  entered  into  the  real-time  application  of  the  dSPACE  software. 

A  more  complex  or  active  payload  may  require  software  modifications  in  addition 
to  the  new  inertia  values.  New  SlMULlNK  code  designed  for  experimental  use  should  also 
be  tested  using  off-line  simulation  with  an  updated  software  plant  model.  This  activity 
should  occur  prior  to  integration  with  the  actual  SIMSAT  hardware. 

^he  SIMSAT  User’s  manual  provides  step-by-step  procedures  for  calculating  and  inputting  new  inertia 
properties  based  on  system  configuration. 
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Figure  5.2  Top-Level  Software  Architecture 


5.2.3  Command  &  Data  Handling.  The  dSPACE  control  suite  provides 
the  command  capability,  data  display  and  recording,  and  user  interface  for  the  SIMS  AT 
system.  Use  of  dSPACE’s  AutoBox  provides  onboard  control  law  processing,  with  wireless 
communications  used  for  upload  of  commands  and  download  of  telemetry  data. 

5.2. 3.1  AutoBox.  AutoBox  incorporates  32-input/32-output  data  chan¬ 
nel  capability  while  providing  onboard  processing.  Payload  interfaces  include  16-input/8- 
output  channels  on  the  primary  payload  side  (AutoBox-side),  as  well  as  8-input  /4-output 
channels  on  the  secondary  payload  side  (momentum  wheel-side).  These  payload  interfaces 
are  wired  in  4-channel  banks  that  can  be  selected  by  the  experimenter.  The  input /output 
channel  interface  board  is  shown  in  Figure  5.3. 


Figure  5.3  Input /Output  Channel  Interface 

5. 2. 3. 2  Command  and  Control  Interface.  The  Cockpit  ground 
control  display,  shown  in  Figure  5.4,  allows  command  capability  using'a  ground-based  PC. 
The  graphical  user  interface  (Grnd-Ctrl.ccs)  was  designed  for  use  with  the  baseline  system, 
and  passive  payloads  can  be  supported  without  modification.  Active  control  of  experiments 
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from  this  user  interface  is  possible,  but  the  user  must  design  any  additional  instruments 
based  on  experiment  needs.  The  user  interface  includes  the  following  instruments2: 

•  Slide  bars  (3)  for  general  Roll,  Yaw,  and  Pitch  angle  control. 

•  Numeric  Inputs  (3)  for  entering  the  exact  Roll,  Yaw,  and  Pitch  angle  commands. 

•  Incremental  Input  instruments  (3)  for  fine  control  of  Roll,  Yaw,  and  Pitch  angles. 

•  Pushbuttons  (3)  for  Roll,  Yaw,  and  Pitch  “return  to  zero”  commands. 

•  Numeric  Displays  (12)  of  Roll,  Yaw,  and  Pitch  angles  (both  commanded  and  mea¬ 
sured)  and  angular  velocities,  as  well  as  momentum  wheel  speeds  in  RPM. 

•  Gauges  (6)  providing  graphical  feedback  on  Roll,  Yaw,  and  Pitch  angular  velocities 
and  momentum  wheel  speeds. 

•  Alert  (1)  to  indicate  Pitch  angle  reaching  limits. 

5. 2. 3. 3  Telemetry  Display.  Figure  5.5  illustrates  the  Trace  tem¬ 
plate  design  used  to  provide  real-time  display  of  motion  variable  time  histories  (SSM- 
TRACE.tpl).  As  shown,  there  are  three  graphing  areas;  the  largest  area  plots  Roll,  Yaw, 
and  Pitch  angles,  and  the  two  smaller  plot  areas  include  angular  velocities  and  momentum 
wheel  speeds. 


5. 2.3. 4  3-D  Real-Time  Animation.  RealMotion  provides  3-D  ani¬ 
mation  of  real-time  SIMS  AT  motion  or  stored  simulations.  The  geometric  model  of  SIM- 
SAT  (Simsat.dxf)  is  linked  with  the  real-time  software,  providing  continual  updates  of  the 
Roll,  Yaw,  and  Pitch  angles.  The  RealMotion  display  is  provided  in  Figure  5.6. 

2This  user  interface  can  be  adjusted  to  include  active  payload  control  variables  as  necessary. 
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Figure  5.4  Cockpit  Graphical  User  Interface 
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Figure  5.5  Trace  Telemetry  Display 
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Figure  5.6  RealMotion  3-D  Animation  Display 
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5. 2. 3. 5  Wireless  Communications.  Cockpit  and  Trace  data  are 
transferred  to  and  from  the  ground  using  RadioLAN  wireless  LAN  products.  The  ISA 
CardLINK  Model  101c  is  connected  to  the  ground  station  PC,  and  a  DockLINK  Model  408 
(shown  in  Figure  5.7)  is  connected  to  the  AutoBox  using  the  network  connection.  For  the 
transfer  of  RealMotion  data,  the  Digital  Wireless  Corporation  WIT2400  Developer’s  Kit 
includes  two  wireless  modems,  self-contained  battery  packs,  battery  charger,  flow  control 
indicators,  dipole  antennas,  RS-232  interface,  and  configuration  software.  Purchase  of 
the  wireless  modem  kit  will  be  delayed  until  successful  integration  of  the  wireless  LAN 
system  is  completed.  An  interface  connector  to  convert  RS-232  to  RS-422  protocol  is 
required  for  modem  integration.  Black  Box  Corporation  produces  a  line  of  converters  for 
this  application  [6].  Conversation  with  Black  Box  technical  support  indicated  that  two 
RS-232  to  RS-422  non-powered  converters  are  available:  the  IC473A  (male  or  female) 
connector  is  used  for  a  DB9  connection,  and  the  IC470A  (male  or  female)  is  used  for  a 
DB25  connection  [7].  At  the  time  of  this  writing,  the  feasibility  of  the  Black  Box  converters 
with  the  AutoBox’s  RS-422  output  port  are  unknown. 


Figure  5.7  Onboard  Wireless  Communications  System 
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5.2.4  Power  System.  The  SIMSAT  power  subsystem  consists  of  batteries 
and  associated  wiring  located  onboard  the  satellite.  Figure  5.8  shows  a  schematic  of  the 
SIMSAT  power  architecture.  Power  is  provided  from  three  rechargeable  Power-Sonic  PS- 
12180  sealed  lead-acid  batteries,  shown  in  Figure  5.9.  The  sealed  design  of  the  PS-12180 
allows  for  unrestricted  operation  under  all  possible  SIMSAT  orientations.  Each  battery  is 
nominally  rated  with  an  18-Ahr  capacity  at  a  DC  operating  voltage  of  12V.  The  battery 
case  is  made  of  non-conductive  polystyrene  for  high  impact  resistance.  Battery  mass  is 
approximately  5.9kg  each.  Series  wiring  of  the  batteries  allows  for  a  nominal  36V  provided 
to  the  momentum  wheels.  Additionally,  12V,  24V,  and  36V  bus  connections  are  provided 
for  powering  SIMSAT  components  or  experimental  hardware. 


Figure  5.8  System  Wiring  Diagram 

In  the  event  of  excessive  gas  buildup  within  a  battery,  a  one-way  neoprene-rubber 
relief  valve  provides  a  safety  mechanism  to  ensure  safe  depressurization  without  case  rup¬ 
ture  occurring.  Vent  release  pressure  is  between  2-6  psi.  Each  battery  is  mounted  within 
an  aluminum  enclosure  that  acts  as  a  mounting  interface  to  the  SIMSAT  truss  structure, 
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Figure  5.9  Power-Sonic  PS-12180  Sealed  Lead-Acid  Battery 

as  well  as  providing  additional  safety  in  the  event  of  a  battery  leak.  This  arrangement  also 
allows  for  ease  of  battery  changeout  between  experiments. 

Total  power  capacity  of  the  baseline  SIMSAT  is  35.1Ahr  at  the  0.5C  (1.3  hr)  discharge 
rate,  or  29.7Ahr  at  the  1.0C  (33  min)  discharge  rate.  A  total  available  continuous  current 
of  27A  is  possible  at  the  0.5C  rate,  or  54A  at  the  1.0C  rate.  Additional  current  may  be 
drawn  for  brief  periods  of  time  but  is  not  sustainable  and  may  decrease  lifetime  battery 
performance. 

Warning  of  a  low  power  condition  is  provided  by  a  Macromatic  VMP024D  voltage 
monitoring  relay  wired  across  two  of  the  three  SIMSAT  batteries.  The  relay  de-energizes 
when  the  monitored  voltage  drops  below  23.3V,  corresponding  to  a  remaining  system 
battery  capacity  of  approximately  10%. 

Wiring  for  the  SIMSAT  batteries  and  components  is  routed  through  the  hollow  cen¬ 
tral  sphere  to  provide  connectivity  between  both  sides  of  the  SIMSAT  truss  structure. 
Wire  gauges  were  selected  to  ensure  an  adequate  level  of  protection  against  overheating. 
Nominal  wire  gauges  for  SIMSAT  components  are  shown  in  Table  5.4. 
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Table  5.4  Nominal  Wire  Gauges 


Component 

Current  (A) 

Voltage  (V) 

Power  (W) 

Minimum  Wire  Gauge 

Autobox 

2.5 

24 

60 

18 

Motor/ Amp  1 

20 

36 

720 

12/14 

Motor/ Amp  2 

20 

36 

720 

12/14 

Motor/ Amp  3 

20 

36 

720 

12/14 

Receiver/Transmitter 

0.5 

12 

6 

27 

Gyro 

1.78 

28 

50 

18 

Thrusters  (2) 

0.75 

32 

24 

18 

With  the  exception  of  wiring  from  the  batteries  to  the  amplifiers,  all  SIMS  AT  com¬ 
ponents  are  wired  through  a  12V,  24V,  or  36V  bus  bar.  On  the  payload  side  of  SIMSAT 
the  bus  bars  are  mounted  on  the  reverse  side  of  the  gyro/battery/transceiver  mounting 
plate.  On  the  momentum  wheel  side  of  SIMSAT ,  the  buses  are  located  on  the  reverse  side 
of  the  primary  battery  mounting  plate.  A  multi-strand  power  connector  cable  runs  from 
all  three  payload-side  buses  to  the  payload  plate.  The  power  connector  cable  allows  for 
power  outputs  of  up  to  60W,  120W,  and  180W,  for  experiments  running  at  12V,  24V,  and 
36V,  respectively.  Payload  power  connection  cables  are  not  provided  on  the  momentum 
wheel  side  of  the  baseline  SIMSAT;  however,  this  capability  can  be  readily  added  should 
the  need  arise. 


5.3  Structural  Layout 

The  SIMSAT  structure  supports  individual  components  and  acts  as  a  skeleton  for  the 
entire  system.  The  SIMS  A  T  structure  consists  of  two  box  trusses  attached  to  the  mounting 
arms  of  the  central  air-bearing  assembly.  Aluminum  and  steel  axe  used  almost  exclusively 
as  construction  materials,  with  Lexan  used  as  a  cover  surrounding  the  momentum  wheel  as¬ 
sembly.  Maximum  use  of  standard  components  and  interfaces  within  the  structural  design 
allows  for  increased  modularity  and  the  ability  to  reconfigure  SIMSAT  to  meet  changed 
requirements.  Modular  design  also  provides  for  easy  access  to  items  (such  as  batteries) 
which  must  be  removed  or  serviced  between  experiments.  Figures  5.10  and  5.11  illustrate 
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the  final  structural  design.  (All  figures  in  this  section  follow  the  structural  description 
ending  on  page  5-18.) 

The  baseline  SIMSAT  structure  (baseplates,  mounting  plates  and  8  support  rods) 
has  a  total  mass  of  approximately  37.5  kg.  Each  side  of  the  SIMSAT  structure  is  based 
upon  a  box  truss  construction  using  standard  plates  and  stringers.  Each  truss  is  mounted 
to  the  air-bearing  with  an  aluminum  7075-T7  collar  (see  Figure  5.12).  Each  cylindrical 
collar  has  an  outer  diameter  of  4.875”  and  a  height  of  2”.  A  2”  diameter  hole  is  centered 
on  the  circular  face  of  the  collar  to  allow  for  cable  routing  through  the  hollow  mounting 
shaft  and  central  sphere.  The  collar  also  has  a  counterbore  (3/16”  deep  and  3”  diameter) 
designed  to  overlap  the  air  bearing’s  mounting  shaft.  This  counterbore  overlap  reduces  the 
shear  stress  on  the  collar-to-mounting-shaft  attachment  screws. 

Base  plates  allow  for  the  attachment  of  each  truss  to  its  respective  collar,  and  mount¬ 
ing  plates  provide  attachment  points  for  individual  components.  A  standard  template  is 
used  for  all  plates,  which  are  available  in  a  variety  of  thicknesses  (1/2”,  1/4”,  3/16”,  1/8”, 
and  3/32”).  Aircraft-grade  aluminum  is  used  in  all  instances:  aluminum  7075-T6  for  1/8” 
and  3/16”  plates,  aluminum  7075-T7  for  3/32”  plates,  and  aluminum  2024  for  1/2”  and 
3/32”  plates.  The  base  (innermost)  plates  are  1/2”  thick  and  are  connected  to  the  truss 
attachment  collars;  component  mounting  plates  may  be  thinner  to  reduce  structural  weight 
if  load  limits  are  not  exceeded. 

All  plates  are  53  cm  (20.866”)  tall  by  35  cm  (13.78”)  wide  (see  Figure  5.13).  Four  1” 
diameter  holes  are  located  on  the  corners  of  each  plate  with  centers  offset  4.4  cm  (1.732”, 
vertically  and  horizontally)  from  the  outer  edgeline.  These  holes  allow  the  mounting  plates 
to  slide  onto  the  main  steel  support  rods.  Four  10-32  threaded  holes  (centers  located 
0.5”  in  vertically  and  horizontally  from  edgeline)  provide  mounting  points  for  L-bracket 
attachments.  These  L-brackets  allow  for  diagonal  cross-members  to  be  attached  between 
mounting  plates  (see  Figure  5.14).  Diagonal  cross-members  are  not  included  in  the  baseline 
SIMSAT  design,  but  can  be  added  to  provide  additional  stiffness  if  improved  vibratory 
response  is  required. 
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The  main  truss  support  rods  are  60  cm  (23.6”)  long  with  an  outer  diameter  of  1” 
and  a  wall  thickness  of  0.065”.  Each  of  the  eight  rods  is  constructed  from  stainless  steel 
316  tubing  with  one  end  plugged  with  a  metal  insert.  The  plugged  end  of  each  rod  is 
placed  through  the  base  plate  and  mated  with  a  connecting  bolt  to  secure  the  rod  in  place. 
This  arrangement  allows  for  minimal  protrusion  on  the  inside  of  the  base  plate,  thereby 
lessening  interference  with  the  overall  SIMS  AT  pitch  envelope. 

The  mounting  plates  are  feed  to  their  positions  along  the  support  rods  through  the 
use  of  metal  clamp-on  collars  (with  a  1”  bore  hole).  Each  mounting  plate  has  a  total  of 
eight  collars  (one  collar  for  each  side  of  the  four  mounting  holes)  to  prevent  movement  of 
the  mounting  plate  along  the  support  rod.  Mounting  plates  can  be  adjusted  and  secured  to 
different  points  along  the  support  rods  to  accommodate  equipment  changes  and/or  gross 
balance  requirements.  One-piece  collars  are  used  primarily  for  mounting  plates  not  subject 
to  frequent  adjustment,  while  two-piece  collars  allow  for  easy  take-on/take-off  in  situations 
where  access  is  routinely  required.  Each  collar  is  made  from  aluminum;  a  two  piece  collar 
weighs  0.04  kg  and  a  one  piece  collar  weighs  0.035  kg  (weight  includes  the  cap  screws). 
The  cap  screws  used  to  tighten  the  clamp-on  collars  are  manufactured  from  alloy  steel. 

The  payload  plate  is  the  mounting  plate  furthest  from  the  central  sphere  located 
on  the  AutoBox  side  of  SIMSAT  (see  Figure  5.15).  This  1/4”  thick  mounting  plate  is 
identical  to  a  standard  mounting  plate,  with  the  addition  of  212  threaded  holes  (5/16” 
diameter)  spaced  1”  apart  (horizontally  and  vertically)  between  centers.  These  holes  are 
referred  to  collectively  as  a  “pegboard”  surface.  The  pegboard  allows  the  user  to  attach 
experimental  payloads  or  balancing  weights  to  the  payload  plate  with  a  maximum  amount 
of  flexibility.  Carbon  steel  blocks  of  nominal  5  kg  and  1  kg  masses  allow  for  gross  balancing 
of  the  SIMSAT  structure.  These  blocks  can  be  attached  to  the  pegboard  using  5/16” 
bolts.  Experiments  can  be  attached  directly  to  the  pegboard  with  bolts  or  indirectly  using 
mounting  brackets  attached  to  the  experiment. 

In  addition  to  carbon  steel  blocks  attached  to  the  payload  plate,  gross  SIMSAT 
balancing  can  be  accomplished  with  53cm  by  35cm  steel  counterweight  plates.  Four  2  kg 
counterweight  plates  are  available  and  four  5  kg  plates  are  available.  These  plates  are  cut 
from  the  standard  plate  template  except  they  have  lightening  holes  to  provide  the  specified 
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mass.  The  2  kg  plates  are  nominally  1/16”  thick  with  a  6.72”  diameter  hole  in  the  center. 
The  5  kg  plates  are  nominally  3/16”  thick  with  a  9.9”  hole  in  the  center.  These  plates 
give  the  user  flexibility  to  place  counterweight  near  the  base  plate  (closer  in  towards  the 
central  sphere)  to  reduce  inertia  penalties. 

Fine-tuning  of  SIMS  AT  balance  is  accomplished  with  a  counterweight  mechanism  (see 
Figure  5.16).  The  counterweight  mechanism  can  be  mounted  on  either  side  of  SIMSAT 
depending  on  balancing  needs.  This  mechanism  relies  upon  orthogonal  1/4”  stainless  steel 
threaded  rods,  hollow  cylindrical  weights  (each  with  a  1/4”  hole),  and  small  steel  clamp-on 
collars  (1/4”  bore).  The  hollow  cylindrical  weights  slide  over  the  threaded  rods  and  are 
held  in  place  with  the  small  clamp-on  collars.  Six  100  gram  and  five  500  gram  hollow 
weights  are  available.  Hand  knobs  on  the  ends  of  the  threaded  rods  allow  the  user  to  make 
slight  adjustments  in  weight  position  by  turning  clockwise  or  counterclockwise. 

Individual  components  are  attached  to  their  respective  mounting  plates  using  a  vari¬ 
ety  of  structural  support  mechanisms.  The  momentum  wheels  are  attached  to  a  mounting 
plate  using  a  cantilevered  support  ‘shelf’  structure  (Figure  5.17  shows  the  shelf  assem¬ 
bly  from  the  fabrication  shop,  with  one  motor  mounted).  A  safety  housing  encloses  the 
momentum  wheels  on  all  sides;  this  prevents  loose  objects  from  being  ejected  by  rotating 
parts.  The  housing  consists  of  a  six-sided  Lexan  box  which  extends  outside  of  the  truss 
bay  in  the  z-direction  (see  Figure  5.18).  Five  sides  of  the  box  are  attached  together  and 
affixed  to  a  separate  mounting  plate.  The  sixth  side  of  the  box  consists  of  a  Lexan  sheet 
mounted  to  the  same  plate  as  the  momentum  wheels.  During  SIMSAT  assembly,  the  five¬ 
sided  Lexan  box  ‘slides’  over  the  momentum  wheels  until  a  solid  press  fit  is  achieved;  the 
final  configuration  is  similar  to  that  of  a  cake  box  used  to  transport  baked  goods  without 
damage.  All  Lexan  sheets  used  to  construct  the  box  are  0.220”  thick.  Clearance  between 
the  momentum  wheels  and  the  interior  of  the  lexan  box  is  approximately  0.5”  to  1.0”. 
The  cake  box  configuration  allows  the  user  to  remove  only  the  exterior  mounting  plates 
for  access  to  momentum  wheels  and  motors  during  maintenance. 

Each  battery  is  attached  to  its  respective  mounting  plate  using  an  aluminum  housing 
which  partially  encloses  the  battery  on  all  six  sides  (see  Figure  5.19  and  Figure  5.20).  Two 
nylon-tipped  bolts  are  mounted  through  the  backplate;  these  bolts  can  be  tightened  to 
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press  upon  the  battery  contact  plate  (held  on  the  battery  with  adhesive)  to  ensure  a  snug 
fit.  The  removable  backplate  allows  for  easy  access  and  replacement  of  the  battery  between 
experiments.  The  battery  housing  does  not  enclose  the  terminal  leads  so  quick-disconnect 
wiring  connections  can  be  made  to  the  batteries.  The  battery  housing  is  attached  to  the 
mounting  plate  via  four  bolts. 

The  AutoBox  is  attached  to  its  respective  mounting  plate  using  a  combination  of  bl¬ 
and  L-brackets.  (see  Figure  5.21).  Polyurethane  padding  is  inserted  between  the  brackets 
and  the  Autobox  to  provide  adequate  vibration  isolation  for  electronic  components. 

An  aluminum  gyroscope  housing  provides  a  support  and  mounting  structure  for  the 
Humphrey  gyro.  To  isolate  the  gyro  from  vibration,  several  rubber  vibration  control 
mounts  and  snubbing  washers  have  been  purchased.  These  vibration  control  mounts  and 
snubbing  washers  can  be  used  to  isolate  the  gyro  housing  attachment  screws  from  the 
mounting  plate.  The  RadioLAN  transceiver  is  attached  directly  to  the  mounting  plate 
using  integral  screw  attachments  (see  Figure  5.22  and  Figure  5.23). 


5-18 


5-19 


ppo: 


Figure  5.11 


Partially- Assembled  SIMS  AT  in  the  Laboratory 
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(a)  Mounting  Collars 


(b)  Collar  Attachment 

Figure  5.12  Truss  Attachment  Collars 
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Figure  5.13  Standard  Plate 
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Figure  5.14  Cross  Member  Attachment  Using  L-brackets 


Figure  5.15 


Payload  Mounting  Plate 
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Figure  5.16 


Counterweight  Mechanism 


Figure  5.17  Momentum  Wheel  Shelf  Assembly 
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Figure  5.18  Lexan  Box 
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Figure  5.19  Battery  Housing 


Figure  5.20  Batteries  and  Battery  Housings  on  Mounting  Plate 
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Figure  5.23  Rubber  Vibration  Control  Mounts  and  Snubbing  Washers 


5-4  Support  Assembly 

Between  experiments,  SIMS  AT  is  removed  (with  a  portable  hydraulic  crane)  from  the 
air-bearing  pedestal  and  placed  on  a  stanchion  support  assembly.  This  support  assembly 
provides  for  workbench  access  when  SIMSAT  is  not  in  use.  Support  stanchion  ‘anti-tip’ 
collars  prevent  SIMS  A  T  from  toppling  during  removal  of  heavy  components  from  one  side 
of  the  SIMSAT  truss. 


5.5  Baseline  SIMSAT  Performance 

The  final  baseline  design  included  46  components  having  the  following  masses  and 
position  vectors.  The  position  vectors  were  measured  from  the  origin  (located  at  the  center 
of  the  central  sphere)  to  the  given  component’s  center  of  mass.  Table  5.5  lists  the  properties 
of  each  component. 

To  properly  balance  the  baseline  system,  a  counterweight  with  the  following  charac¬ 
teristics  was  used.  This  counterweight  was  also  assumed  to  represent  a  nominal  payload 
attached  to  SIMSAT  (see  Figure  5.24). 


Mass:  18.927  kg  =  41.6  lb 
bl  dimension:  5.08  cm  (2.0  in) 
b2  dimension:  46.6  cm  (18.3  in) 
b3  dimension:  10.16  cm  (4.0  in) 


r  counterweight 


-0.7493 

-0.0219 

0.0013 


m 


Using  AutoCAD  and  Matlab,  the  final  inertia  matrix  of  the  baseline  design  (including 
the  counterweight)  was: 
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Table  5.5  Baseline  Components,  Masses,  and  Positions 


Component 

Mass 

_ m _ flb) _ 

Position  Vector 

(from  origin  to  item's  c.g.  in  cm) 

Sphere  &  mounting  shafts 

19.3182 

42.500 

[0,  0,  0] 

|Mom.  wheel  side: 

1 

2  Batteries 

11.95 

26.290 

(37.465,  0,  0] 

2  Battery  housings 

2.714 

5.971 

[38.5651,0,0] 

3  Amps 

1.995 

4.389 

[48.0608,  0,  0] 

3  Motors 

9.81 

21.582 

[62.9051,  1.4268,0.1284] 

Wheel  #1 

2.06 

4.532 

[71.35,  -5.735,  2.97] 

Wheel  #2 

2.06 

4.532 

[62.9,12.715,-11.3] 

Wheel  #3 

2.06 

4.532 

[62.9,5.735,  17.1499] 

Wheel/Motor  shelves 

4.127 

9.079 

[59.1033,-1.3287,  -2.2075] 

Lexan  box 

5.741 

12.630 

[63.3721,0,-1.7922] 

4  Support  rods 

2.316 

5.095 

[59.4141,0,0] 

Base  Plate  1 

6.596 

14.511 

•  [30.0491,0,0] 

Mounting  Plate  1 

3.298 

7.256 

[42.1175,0,0] 

Mounting  Plate  2 

3.298 

7.256 

[49.6825,  0,  0] 

Mounting  Plate  3 

3.298 

7.256 

[77.4351,0,0] 

Truss  attachment  collar  1 

1.603 

3.527 

[26.93,  0,  0] 

Total  mass  mom  whl  side: 

62.926 

138.4372 

|Autobox  side: 

AutoBox 

8.6 

18.920 

[-59,  0,  0] 

AutoBox  U-bracket 

0.164 

0.361 

[-61.969,  0,  0] 

4  AutoBox  L-brackets 

0.032 

0.070 

[-50.5731,0,  0] 

Battery  #3 

5.975 

13.145 

[-38.1625,0,0] 

Battery  #3  housing 

1.357 

2.985 

[-37.0623,0.3319,-1.8028] 

Gyro 

1.05 

2.310 

[-38.3,18.6,  0] 

Gyro  housing 

0.178 

0.392 

[-41.4615,  18.162,  0] 

T  ransceiver/antenna 

0.838 

1.844 

[-39.611,-18.7611,0] 

4  Support  rods 

2.316 

5.095 

[-59.4141,0,  0] 

Base  Plate  2 

6.596 

14.511 

[-30.0491,0,0] 

Mounting  Plate  4 

3.298 

7.256 

[-43.035,  0,  0] 

Mounting  Plate  5 

3.298 

7.256 

[-48.9325,  0,  0] 

Payload  Plate 

3.298 

7.256 

[-72.0675,  0,  0] 

Truss  attachment  collar  2 

1.603 

3.527 

[-26.93,  0,  0] 

Counterwt  (nominal  payload) 

18.927 

41.639 

[-74.925,  -2.19,0.13] 

Total  mass  Abox  side: 

57.53 

126.566 

Total  SI  MS  AT  mass: 

139.7742 

307.503 

[0,  0,  0] 

Notes: 

1 .  Plates  are  aluminum  7075  or  2024  and  support  rods  are  stainless  steel  316- TOD,  0.065"  wall  thickness,  60  cm  long 

2.  All  plates  are  53x35  cm--base  plates  are  M2"  thick,  mounting  plates  are  assumed  to  be  1/4"  thick 
(3/16",  1/8"  and  3/32"  thick  mounting  plates  are  also  available) 

3.  Coordinate  origin  is  located  at  the  center  of  the  central  sphere 
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2"  X  18.3"  x  4"  steel  block 


e  5.24  Baseline  SIMSAT  Layout  with  Nominal  Payload  and  Body-Fixed  Axes 


3.1592 


-0.4214 


0.1161 


7 comp  — 


-0.4214  44.0099  0.0026 

0.1161  0.0026  45.3174 


kg  in2 


Using  this  baseline  configuration,  several  system  simulations  were  performed.  The  results 
of  these  simulations  are  listed  in  Appendix  M. 

5. 6  Areas  Requiring  Further  Integration 

At  the  time  of  this  writing,  major  SIMS  AT  structural  components  were  under  fabrica¬ 
tion  by  AFIT  technical  personnel,  and  initial  testing  of  SIMS  AT  components  was  ongoing. 
Full  completion  of  the  SIMS  AT  baseline  design  will  not  be  complete  until  mid- 1999,  re¬ 
quiring  additional  work  by  AFIT  students  and  technicians.  The  following  areas  are  listed 
as  known  items  requiring  integration: 

•  SIMS  AT  structural  assembly. 

•  Physical  installation  of  components  onto  the  SIMS  AT  structure. 

•  Detailed  signal  interface  between  components  and  the  AutoBox. 

•  Fabrication  of  signal/power  connections,  as  designed,  for  experimental  payloads. 

•  Wiring  of  SIMS  AT  components  in  accordance  with  current  design  drawings. 

•  Detailed  development  of  SIMS  AT  safety  system. 

•  Development  of  higher  fidelity  motor /motor  controller  transfer  function. 

•  Control  software  validation  using  the  SIMS  AT  hardware. 


5.7  Recommended  Future  Design  Activity 

During  the  course  of  SIMS  AT  design,  additional  areas  for  potential  research  were 
recognized  but  not  pursued  due  to  time  limitations.  The  design  team’s  focus  on  producing 
a  baseline  SIMS  AT  configuration  excluded  several  promising  concepts  from  implementation 
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to  reduce  overall  project  risk.  These  concepts  could  form  the  basis  for  future  experimental 
work. 


5.7.1  IPACS.  The  use  of  chemical  batteries  to  provide  SIMSAT  power 
was  based  partially  on  the  desire  to  implement  a  mature  power  system  requiring  minimal 
development.  Chemical  batteries,  however,  are  heavy  in  comparison  to  other  potential 
power  sources.  Previous  AFIT  design  work  examined  the  potential  for  an  Integrated 
Power  and  Attitude  Control  System  (IPACS)  combining  energy  storage  and  momentum 
transfer  capability  into  a  single  system  [23].  IPACS  holds  the  potential  for  future  significant 
reductions  in  overall  subsystem  mass  required  for  power  and  attitude  control;  the  use  of 
SIMSAT  as  a  testbed  for  this  research  is  suggested. 

5.7.2  CMGs.  As  mentioned  in  previous  chapters,  the  choice  of  momentum 
wheels  was  largely  based  upon  cost  limitations.  Clearly,  the  best  option  for  achieving  high 
slew  rates  is  through  the  use  of  control  moment  gyros  (CMGs).  In  the  future,  it  may  be 
possible  to  remove  the  momentum  wheel  package  and  replace  it  with  a  CMG.  Additional 
work  will  be  necessary  to  modify  the  existing  equations  of  motion  and  control  laws  needed 
to  utilize  this  new  actuation  system.  However,  such  a  system  shows  promise  in  performing 
realistic  slew  maneuvers  for  pointing  experiments. 

5.7.3  Thrusters.  As  discussed  in  depth  during  Detailed  Design,  SIMSAT 
was  designed  for  future  compatibility  with  cold-gas  jet  thruster  systems.  The  Moog  Model 
50-820  cold-gas  thruster  triad  was  used  as  the  baseline  for  future  thruster  development. 
In  addition  to  the  possibility  of  using  the  Model  50-820,  other  options  may  be  possible. 
Near  the  end  of  SIMSAT  development,  the  design  team  became  aware  of  a  new  thruster 
package  developed  by  the  University  of  Cincinnati  for  use  on  a  NASA  sounding  rocket  [1]. 
This  design  may  also  prove  to  be  compatible  with  the  baseline  SIMSAT  configuration,  and 
may  indicate  the  opportunity  for  future  collaborative  efforts. 

5.7.4  Micro  AutoBox.  During  SIMSAT  development,  a  new  product  from 
dSPACE  became  commercially  available  -  the  MicroAutoBox  (shown  in  Figure  5.25).  This 
product  is  specifically  designed  for  applications  requiring  small,  powerful  processing,  such 
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as  the  SIMS  AT  design.  The  Micro  AutoBox  provides  similar  processing  capability  as  the 
AutoBox,  but  the  use  of  miniaturized  cards  and  tight  design  allows  a  much  smaller,  lighter 
physical  envelope.  Unfortunately  for  the  baseline  design,  this  product  was  not  available 
in  time  for  system  consideration.  The  MicroAutoBox,  however,  represents  a  future  avenue 
in  the  reduction  of  system  weight  and  inertia,  thereby  increasing  overall  performance. 
Information  about  this  product  is  listed  on  the  dSPACE  website  [21]. 


Figure  5.25  The  dSPACE  MicroAutoBox  [21] 

5.7. 4-1  ControlDesk.  Another  new  dSPACE  product,  the  ControlDesk 
experimental  software  suite,  represents  an  integrated  command  interface  and  telemetry 
display.  This  package  can  be  considered  for  future  use  to  replace  the  individual  Cock¬ 
pit  and  Trace  interfaces  with  one  integrated  user  interface.  This  would  allow  both 
the  command  and  telemetry  controls  and  variables  to  be  viewed  simultaneously,  without 
the  need  to  reduce  (or  minimize)  screen  windows  or  use  a  two-monitor  configuration. 
Experimental  software  packages  are  described  on  dSPACE’s  website  [20] . 

5.7.5  Dual  Spinner.  The  capability  to  simulate  a  dual-spin  satellite  was 
a  secondary  objective  for  the  design  project.  To  perform  this  function,  the  momentum 
wheel  assembly  would  be  removed.  Two  lexan  boxes,  each  containing  one  momentum 
wheel,  would  be  aligned  along  the  roll  axis  on  either  side  of  SIMS  AT.  One  momentum 
wheel  would  provide  the  necessary  torque  to  spin  the  vehicle.  After  the  desired  spin  rate 
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is  achieved  the  opposite  momentum  wheel,  acting  as  the  platform,  would  rotate  opposite 
the  body  at  the  same  angular  rate.  To  an  observer,  the  wheel  would  appear  as  though  it 
is  not  rotating. 

5. 8  Conclusions 

Once  fully  assembled  and  integrated,  the  SIMSAT  design  will  meet  the  needs  of 
AFIT  in  providing  a  realistic  space-platform  simulator  for  experimenters.  The  design 
team  achieved  the  top-level  goals  of  developing  a  baseline  satellite  simulation  tool  using 
the  systems  engineering  approach,  weighing  cost,  schedule,  safety,  and  performance  objec¬ 
tives  throughout  the  design  process.  Following  successful  integration,  SIMS  A  Twill  provide 
an  in-house,  modular,  and  robust  testbed  for  the  following  research  and  educational  appli¬ 
cations: 

•  Three-axis  stabilization  experiments. 

•  Satellite  pointing  and  tracking. 

•  Rigid  and  flexible  structure  experimentation. 

•  Pure  and  dual  spinner  demonstrations. 

•  Test  and  evaluation  of  various  controllers. 

•  Remote  communications  and  time-delay  control. 

•  Satellite  dynamics  educational  tool. 

•  Momentum  wheel  and  thruster  research  and  development. 

•  Computer  visualization/user  interface  development. 

It  is  hoped  that  SIMSAT  will  spur  a  new  era  of  space-technology  development  at 
AFIT,  supporting  the  Air  Force’s  vision  of  maintaining  preeminence  as  the  world’s  leading 
space  and  air  force  well  into  the  next  century. 
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Appendix  A.  Preliminary  Design 

Measurables 

A.l  Overview 

The  measurables  from  the  Preliminary  Design  objective  hierarchy,  shown  in  Fig¬ 
ure  3.5,  are  described  in  detail  in  this  section.  For  each  measurable,  the  resolution  is 
defined  and  the  conversion  from  raw  values  to  scaled  scores  is  displayed.  This  conversion 
allowed  each  measurable  to  be  judged  on  the  same  utility  scale,  which  ranged  from  0  (no 
utility)  to  10  (excellent  utility).  The  data  points  listed  under  each  measurable’s  value 
function  correspond  to  the  direct  inputs  given  by  the  decision  makers.  From  these  inputs, 
the  curves  were  fitted  to  provide  mathematical  formulas  for  the  conversion  of  raw  data  to 
standardized  utility  values. 

The  data  in  this  section  correspond  to  Appendix  C  of  Mr.  Hanke’s  thesis  [26].  A 
decision-making  software  package,  Logical  Decisions,  was  used  by  Mr.  Hanke  in  the 
generation  of  value  functions  based  on  chief  decision  maker  (CDM)  inputs. 

The  measurables  in  this  appendix  are  grouped  by  top-level  value  (cost,  schedule, 
safety,  and  performance).  Within  each  value,  the  measurables  are  listed  alphabetically. 
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Capital  Cost 


Capital  Cost  50  10  40  70  100  $1,000 

Value  7.00  10.00  7.91  4.76  0.00 

FORMULA:  =1 4.1 1  -3.581  *EXP(0.01 371  *x) 


Figure  A.l  Capital  Cost  Value  Function 

A.  2  Cost 

A. 2.1  Capital  Cost.  This  measure  was  a  continuous  “direct”  measure 
reflecting  the  estimated  total  cost  to  purchase  and  integrate  the  system.  The  costs  included 
all  the  primary  subsystem  components,  support  parts,  and  any  labor  required  for  the  one¬ 
time  fabrication  of  the  system.  The  CDM  generated  this  function  by  selecting  the  following 
value  comparison: 

Value($50,000)  =  7 
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0  2.5  5  7.5  10 

$1 ,000/yr 


O  &  M  Cost 
Value 

FORMULA: 


0  2.5  5  7.5  10  $1 ,000/yr 

10  8.81  7.00  4.23  0.00 

=12.25-2.25*EXP(0.1695*x) 


Figure  A.2  O&M  Cost  Value  Function 

A. 2. 2  Operations  and  Maintenance  Cost.  This  measure  was  a  con¬ 
tinuous  “direct”  measure  reflecting  the  estimated  yearly  cost  to  operate  and  maintain  the 
system.  The  recurring  costs  included  all  the  consumables,  repair  parts,  and  labor  required 
to  keep  the  system  running  each  year.  The  CDM  generated  this  function  by  selecting  the 
following  value  comparison: 

Value($5,000)  =  7 
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Total  Time 
Value 

FORMULA: 


24  32  40  48  56  weeks 

10.00  9.20  7.72  5.00  0.00 

=1 0.96-0.1 539*EXP(0.0761 7*x) 


Figure  A.3  Total  Delivery  Weeks  Value  Function 

A.  3  Schedule 

A. 3.1  Total  Delivery  Weeks.  The  only  measure  for  the  Schedule  funda¬ 
mental  value  is  Total  Delivery  Weeks.  This  measure  was  a  continuous  “direct”  measure 
reflecting  the  summation  of  the  time  required  to  order,  produce,  deliver,  and  integrate  the 
entire  SIMS  AT  system.  The  CDM  generated  this  function  by  selecting  the  following  value 
comparison: 

Value(48  weeks)  =  5 
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A. 4  Safety 


The  Safety  measures  Relative  Damage  Index  and  Relative  Injury  Index  were  based  on 
the  table  shown  in  Figure  A.4.  That  table  was  developed  as  suggested  by  MIL-STD-882B 
[3:7-8,  A3-A4],  as  coordinated  with  the  CDM. 


Failure  Probability 


Severity  of 
Failure: 


Severe  Injury,  Minor  Injury,  Less  than  Minor 


0.01  Likely  to  occur  frequently  Freq 

0.0001  ->  0.01  Occur  several  times  in  5  years  Prob 

0.00001  ->  0.0001  Likely  to  occur  sometime  in  5  years  Occas 
0.000001  ->  0.00001  May  occur  sometime  in  5  years  Rem 
<  0.000001  So  unlikely  can  assume  may  not  fail  tmprob 


Catastrophic 

Critical 

Marginal 

Negligible 

1 

3 

i  * 

10 

2 

5 

3 

12 

4 ........... ...1 

■1  * 

11 

15 

timmm 

12 

.14 

lilllHl:!!!!!!!! 

10 

14 

^  V*  i 

System  Loss  means  at  least  90%  of  SIMSAT  must  be  replaced 
Major  Damage  means  50-90%  of  SIMSAT  must  be  replaced 
Minor  Damage  means  25-50%  of  SIMSAT  must  be  replaced 
Less  than  Minor  damage  means  0-25%  of  SIMSAT  must  be  replaced 

Severe  Injury  means  at  least  1  day  of  work  is  missed 

Minor  Injury  means  a  visit  to  the  hospital  is  required,  but  no  work  is  missed 

Less  than  Minor  Injury  means  that,  at  worst,  only  minimal  first  aid  is  required 


Risk  Index  Acceptability 

1-5  Unacceptable 

6-9  Undesirable 

10-17  Acceptable  with  review 

18-20  Acceptable  as  is 


Figure  A.4  Hazard  Index  Table 
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Rel.  Damage  Index  10  12  14  16  18  20 

Value  0.00  2.00  4.00  6.00  8.00  10.00 

FORMULA:  =-10+x 

Figure  A.5  Relative  Damage  Index  Value  Function 


A. 4.1  Relative  Damage  Index.  See  Figure  A.4  (page  A-5)  for  definition 

of  this  constructed  scale,  a  combination  of  probability  of  failure,  and  severity  of  that  failure. 


Rel.lnjury  Index  10  12  14  16  18  20 

Value  0.00  2.00  4.00  6.00  8.00  10.00 

FORMULA:  =-10+x 


Figure  A.6  Relative  Injury  Index  Value  Function 

A. 4* 2  Relative  Injury  Index .  See  Figure  A.4  (page  A-5)  for  definition  of 

this  constructed  scale,  a  combination  of  probability  of  mishap,  and  severity  of  that  mishap. 
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A. 


Bandwidth  High  Moderate  Low 

Value  0  5  10 


Figure  A. 7  Bandwidth  Requirement  Value  Function 

Performance 

A. 5.1  Bandwidth  Requirement. 


LEVEL 

High 

Moderate 

Low 


DEFINITION 

All  signals  need  to  be  sent 

Display/Command  and  ADACS  signals  need  to  be  sent 
Only  Display/Command  updates  need  to  be  sent 
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Command  Capability 


Command  Capab.  Start/Stop  ADAC  Full 

Value  0  7  10 


Figure  A.8  Command  Capability  Value  Function 

A. 5. 2  Command  Capability. 

LEVEL  DEFINITION 

Start/Stop  Only  ground  start/stop  ground  commands 

ADAC  Only  satellite  attitude  and  direction  controlled 

Full  ADAC  and  payload  controllable  from  ground 
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Figure  A.9  Communications  Latency  Value  Function 

A. 5. 3  Communications  Latency. 


LEVEL 

Significant 

Moderate 

Minimal 


DEFINITION 

Delay  impacts  both  inner  and  outer  control  loops 

Delay  impacts  only  outer  control  loop 

Only  delay  is  between  user  interface  and  control  loop(s) 
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Control  Systems  Analysis 


Control  Sys.  Analysis  Minimal  Partial  Full 

Value  0  7  10 


Figure  A.  10  Control  Systems  Analysis  Value  Function 


A. 5. 4  Control  Systems  Analysis. 

LEVEL  DEFINITION 

Minimal  <50%  of  desired  system  elements  defined  or  the 

remaining  elements  are  difficult  to  define 

Partial  50-90%  of  desired  system  elements  defined;  simple  to 

define  the  rest 

Pull  >90%  of  desired  system  elements  defined 
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Development  Environment 


Develop.  Environment  Text  Graphical  OO 

Value  0  7  10 


Figure  A.  11  Development  Environment  Value  Function 


A. 5. 5  Development  Environment. 


LEVEL 


DEFINITION 


Text 

Graphical 


Object-Oriented 


Time-intensive  entry  of  control  laws;  prone  to  errors 

Not  all  aspects  of  control  system  available  as  “building  blocks” 
but  more  user-friendly  than  Text 

Graphical;  all  critical  elements  available  as  “building  blocks” 
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Experiment  Types 


Experiment  Types  None  Educ.  Rigid  Full 

Value  0  2  7  10 


Figure  A. 12  Experiment  Types  Value  Function 


A. 5. 6  Experiment  Types. 


LEVEL 

None 

Educational 

Rigid 

Full 


DEFINITION 

No  experiments  possible 

Education/teaching  usage  only  (spinner  experiments) 
Supports  spinner  and  3-axis  rigid  experiments 
Supports  all  the  desired  experiments 
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Interface  Mod.  None  Some  Partial  Full 

Value  0  2  6  10 


Figure  A.13  Interface  Modularity  Value  Function 

A. 5.7  Interface  Modularity. 

LEVEL  DEFINITION 

None  Only  complete  subsystems  can  be  replaced 

with  payload  parts,  not  components 

Some  10-50%  of  components/sub-sub-systems  can  be 

relocated  or  substituted  with  payload  parts 

Partial  50-75%  of  components/sub-sub-systems  can  be 

relocated  or  substituted  with  payload  parts 

Full  All  components/sub-sub-systems  can  be  relocated  or 

substituted  with  payload  parts 
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Mainl  &  Test  Time  V_High  High  Mod  Low  V_Low 

Value  0  3  5  7  10 


Figure  A.  14  Maintenance  &  Test  Time  Value  Function 

A. 5. 8  Maintenance  and  Test  Time. 

LEVEL  DEFINITION 

Very  High  Completely  reconfigure  to  conduct  new  experiments; 

requires  system  validation  before  test  run  (>  100  min) 

High  Experiment  installation  and  validation  requires  76-100  min 

total  time 

Mod  Experiment  installation  and  validation  requires  36-75  min 

total  time 

Low  Experiment  installation  and  validation  requires  16-35  min 

total  time 

Very  Low  Snap-in/snap-out;  experiment  installation  and  validation 

requires  0-15  min  total  time 
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Mass  Margin 


Mass  Margin  0  100  200  300  kgs 

Value  0  8.0  9.6  10.0 

FORMULA:  =1 0.08-1 0.08*EXP(-0.01 575*x) 


Figure  A.  15  Mass  Margin  Value  Function 

A. 5. 9  Mass  Margin .  This  measure  was  a  continuous  “direct”  measure 

reflecting  the  estimated  mass  the  air  bearing  assembly  can  support  after  all  the  required 
baseline  SIMS  AT  components  are  installed.  The  CDM  generated  this  function  by  selecting 
the  following  value  comparison: 

Value(100  kg)  =  8 
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Motion  Simulation 


Motion  Simulation  No  Yes 

Value  0  10 


Figure  A.16  Motion  Simulation  Value  Function 

A. 5. 10  Motion  Simulation.  This  measure  was  a  binary  (yes/ no)  measure 
of  whether  the  system  could  support  satellite  behavior  simulation  prior  to  the  execution 
of  an  experiment. 
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FORMULA:  =1 0.56-45.98*EXP(1 .471  *x) 


Figure  A.  17  Rate  Sensing  Accuracy  Value  Function 

A. 5. 11  Rate  Sensing  Accuracy.  This  measure  was  a  continuous  “direct” 
measure  reflecting  how  accurately  SIMS  AT  can  sense  angular  rates.  The  CDM  generated 
this  function  by  selecting  the  following  value  comparison: 

x  =  0.005  -¥  log(a:)  =  —2.301...;  Value(0.005  deg/sec)  =  9 
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Post-Mission  Analysis 
Value 


No 

0 


Yes 

10 


Figure  A.  18  Post-Mission  Data  Analysis  Value  Function 

A. 5. 12  Post- Mission  Data  Analysis.  This  measure  was  a  binary 
(yes/no)  measure  of  the  system  to  support  data  collection  and  retrieval  capability  for 
post-mission  data  analysis. 
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Power  Margin 
Value 

FORMULA: 


0  2  5  8  11  14  15  Amp-Hrs 

0.00  5.00  8.25  9.41  9.82  9.97  9.99 

=10.05  -  10.05  *  EXP(-0.3437*x) 


Figure  A.  19  Power  Margin  Value  Function 

A. 5. 13  Power  Margin .  This  measure  was  a  continuous  “direct”  measure 
reflecting  the  estimated  power  the  battery  system  can  support  after  all  the  required  baseline 
SIMS  AT  components  are  installed  (at  the  nominal  system  voltage).  The  CDM  generated 
this  function  by  selecting  the  following  value  comparison: 

Value(2  Amp-hrs)  =  5 
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Proc.  Sched.  Analys.  None  Unsupported  Moderate  Full 

Value  0  2  7  10 

Figure  A.20  Processor  Schedulability  Analysis  Value  Function 

A. 5. 14  Processor  Schedulability  Analysis.  See  Appendix  A  of  Mr. 

Hanke’s  thesis  [26]  for  additional  rationale  on  Rate  Monotonic  Analysis  (RMA)  as  the 
scheduling  technique  of  choice. 

LEVEL  DEFINITION 

None  RMA  is  not  supported;  insufficient  data  regarding  OS  scheduling 

technique  to  assess  likelihood  and  impact  of  missed  deadlines 

Unsupported  RMA  is  not  supported;  but  sufficient  data  regarding  OS 

scheduling  technique  to  assess  likelihood  and  impact 
of  missed  deadlines 

Moderate  RMA  supported  at  least  indirectly;  some  hand-coding  required 

to  fully  implement 

Full  RMA  supported  directly  in  both  hardware  and  software 
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0) 
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Real-Time  Data  Analysis 


Real-Time  Analysis  No  Yes 

Value  0  10 


Figure  A.21  Real-Time  Data  Value  Function 


A. 5. 15  Real-Time  Data .  This  binary  (yes/no)  measure  indicated  the 

system  support  for  real-time  data  display. 
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Slew  Capability 


Slew  Capability  30  60  90  100  deg/10  sec 

Value  0.00  7.00  9.57  10.00 

FORMULA:  =1 1 .07-30.1*  EXP(-0.03333’x) 


Figure  A.22  Slew  Capability  Value  Function 

A. 5. 16  Slew  Capability.  This  measure  was  a  continuous  “direct”  measure 
reflecting  how  far  SIMS  AT  can  slew  in  a  10  second  timeframe.  The  CDM  generated  this 
function  by  selecting  the  following  value  comparison: 

Value(60  deg  in  10  sec)  =  7 


A-23 


10  1 

<1) 

■g  = 

Slew  Rate  Si 

arising 

—  “  - 

j 

« 

n  - 

. "  •>  •  is"  j 

:Zi ..  ;:§ii! 

V:  '  j 

mmmmmm 

. ;  . j 

' . : .  i 

U  n 

de< 

j/sec 

Slew  Rate  Sensing  deg/sec 

Value 

FORMULA: 


Figure  A. 23  Slew  Rate  Sensing  Value  Function 

A. 5*17  Slew  Rate  Sensing .  Because  the  alternatives  considered  in  the 

Preliminary  Design  phase  did  not  specifically  address  the  rate  gyro  subsystem,  no  al¬ 
ternatives  differed  in  this  rate  sensing  metric  since  all  incorporated  a  nominal  rate  gyro 
subsystem.  Thus,  the  value  function  for  this  measurable  was  determined  to  be  of  no  con¬ 
sequence  at  this  stage  of  design.  In  the  Detailed  Design  phase,  Slew  Rate  Sensing  was 
directly  addressed. 
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Turn-Around  Time  3  0  2  4  6  8  hours 

Value  1.00  10.00  2.17  0.45  0.08  0.00 

FORMULA:  =-0.02279+10.02*EXP(-0.7608‘x) 


Figure  A.24  Turn-Around  Time  Value  Function 

A. 5. 18  Turn-Around  Time.  This  measure  was  a  continuous  “direct” 
measure  reflecting  the  time  between  experimental  runs,  assuming  no  reconfiguration  of 
payload  hardware  is  required.  The  measure  was  impacted  by  both  the  number  of  spare 
batteries  available  and  the  recharge  cycle  time.  For  example,  a  single  set  of  batteries  that 
last  4  hours  and  take  8  hours  to  recharge  would  score  an  8  and  a  value  of  0  (based  upon 
Figure  A.24).  Adding  another  set  of  4  hour  batteries  would  score  a  4  for  a  value  of  0.45, 
while  3  sets  of  batteries  would  allow  the  first  set  to  recharge  by  the  time  the  third  ran 
down,  resulting  in  0  turn-time  for  a  value  of  10.  The  CDM  generated  this  function  by 
selecting  the  following  value  comparison: 

Value(3  hours)  =  1 
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User  Interface 
Value 


Minimal 

0 


Partial 

7 


Full 

10 


Figure  A.25  User  Interface  Value  Function 

A. 5. 19  User  Interface. 

LEVEL  DEFINITION 

Minimal  <50%  of  controls  and  displays  can  be  done  graphically 

Partial  50-90%  of  controls  and  displays  can  be  done  graphically 

Full  >90%  of  controls  and  displays  can  be  done  graphically 
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Appendix  B.  Equations- of -Motion 

Development 

B.l  Overview 

This  appendix  details  the  equations-of-motion  (EOM)  development  used  for  the  mo¬ 
mentum  wheel  sizing  and  system  modeling  of  the  first  Detailed  Design  iteration.  In  addi¬ 
tion,  the  EOM  modeling  served  as  a  basis  for  the  plant  model  for  controller  development 
and  satellite  simulation. 

B.2  Plant  Model 

The  plant  model  was  developed  by  deriving  the  equations  of  motion  of  the  system. 
As  with  any  formal  definition,  there  was  a  basic  process  which  was  followed.  The  steps  of 
this  process  are  listed  below: 

1.  List  any  key  assumptions  for  the  system. 

2.  Define  an  inertial  reference  frame. 

3.  Establish  a  body-fixed  basis  and  reference  point  for  the  system  by  which  all  compo¬ 
nents  will  be  expressed. 

4.  Identify  the  relevant  forces  and  moments  acting  upon  the  system. 

5.  Use  appropriate  fundamental  equations  to  derive  the  specific  system  equations  of 
motion. 

B.3  Key  Assumptions 

1.  The  system  behaves  as  a  rigid  body.  While  this  is  not  a  completely  accurate  state¬ 
ment,  it  simplifies  our  model  by  defining  a  complex  system  using  basic  equations  of 
motion.  However,  it  should  be  understood  that  SIMS  AT  is  not  a  purely  rigid  body 
in  reality  and  will  perform  as  such. 
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2.  The  initial  system  uses  three  momentum  wheels  to  perform  slew  maneuvers  and  main¬ 
tain  pointing  accuracy.  For  the  first  cut,  thrusters  were  not  added  to  the  equations 
of  motion.  This  decision  was  made  due  to  the  team’s  inability  to  purchase  thrusters 
during  system  creation.  While  components  had  been  identified  for  purchase,  perfor¬ 
mance  information  derived  from  lab  testing  was  not  possible.  Therefore,  any  thruster 
model  developed  without  accurate  information  would  be  useless  to  include  within  the 
system. 

3.  SIMS  AT  has  rotational  freedom  about  the  roll  and  yaw  axes.  About  the  pitch  axis, 
there  is  limited  rotational  movement  (±15-30  deg).  This  limitation  is  due  to  the 
pedestal  upon  which  SIMS  AT  rests.  While  this  limitation  did  not  affect  the  equations 
of  motion,  establishing  the  degrees  of  freedom  provided  clarity  to  the  system  design 
and  identified  control  issues. 

4.  There  are  no  external  torques  acting  upon  SIMS  AT.  This  is  an  engineering  approxi¬ 
mation.  In  reality,  there  are  several  external  torques,  such  as  air  drag,  which  affect  the 
motion  of  SIMSAT.  However,  there  were  no  estimates  for  these  torques.  Therefore, 
they  were  ignored  until  the  proper  time  when  these  torques  were  better  understood 
and  could  be  accurately  modeled. 

5.  SIMSATs  origin  matches  the  physical  center  of  SIMSAT,  which  is  located  at  the 
center  of  the  central  sphere. 

6.  All  SIMSAT  components  can  be  modeled  as  simple  geometric  shapes  with  uniform 
density.  While  this  does  not  reflect  the  true  nature  of  the  components,  it  adequately 
simplifies  the  model. 

7.  The  system  is  assumed  to  be  perfect  with  no  losses  due  to  friction  with  the  air  bearing 
or  with  other  components  within  the  system. 

B.4  Inertial  Reference  Frame,  Inertial  Basis,  and  Origin 

The  inertial  reference  frame  selected  for  the  system  was  the  lab  room  in  which  the 
system  is  to  be  contained.  Its  origin  is  the  point  in  space  upon  which  the  center  of  the 
central  sphere  is  located  (when  placed  upon  the  air  bearing  pedestal).  This  point  is  fixed 
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with  respect  to  both  inertial  space  and  the  body  of  SIMS  AT.  Finally,  the  basis  that  defines 
the  inertial  reference  frame  has  +x  pointing  to  the  right  of  the  page,  +y  pointing  towards 
the  top  of  the  page,  and  +z  pointing  out  of  the  page. 

With  respect  to  the  lab  room,  the  inertial  +y  axis  is  pointed  directly  at  the  laboratory 
ceiling.  The  +x  axis  points  at  a  pre-defined  location,  such  as  a  painted  mark  on  the  north 
laboratory  wall  (or  any  other  convenient  wall).  With  the  +x  and  +y  inertial  axes  defined, 
the  +z  inertial  axis  can  be  deduced  from  right-handed  orthogonality.  For  experiments, 
the  body-fixed  basis,  explained  in  the  next  section,  will  be  aligned  with  the  inertial  axis 
system  at  time  t=0. 

B.5  SIMS  AT  Body  Frame,  Body  Fixed  Basis,  and  Refer¬ 
ence  Point 

The  body  frame  for  SIMS  AT  was  defined  as  the  composite  structure.  Its  reference 
point,  the  physical  center  of  the  body,  rests  on  the  origin  of  the  inertial  reference  frame. 
Using  the  document  below,  the  b  basis  has  bl  pointing  to  the  right  of  the  page,  b2  pointing 
towards  the  top  of  the  page,  and  b3  pointing  out  of  the  page.  This  orthogonal  axis  set  was 
used  as  the  common  basis  by  which  all  components  of  SIMS  AT  were  expressed.  It  is  fixed 
to  the  SIMS  AT  body  and  rotates  with  the  vehicle.  With  respect  to  the  b  basis,  the  axle  of 
wheel  1  was  parallel  to  the  bl  axis,  the  axle  of  wheel  2  was  parallel  to  the  b2  axis,  and  the 
axle  of  wheel  3  was  placed  parallel  to  the  b3  axis.  Figure  B.l  illustrates  this  arrangement. 

In  addition  to  the  b  basis,  each  component  had  its  own  frame  and  orthogonal  axis  set 
fixed  about  its  own  center  of  mass  in  accordance  with  Appendix  B  in  Kramer’s  text  [31]. 
Each  momentum  wheel  had  a  specific  basis  that  was  used  throughout  the  development  of 
the  equations  of  motion  (and  subsequent  programming  codes).  Momentum  wheel  one  uses 
the  d  basis,  momentum  wheel  two  uses  the  f  basis,  and  momentum  wheel  3  uses  the  h 
basis.  These  letters  were  arbitrarily  picked  and  have  no  special  significance. 
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Imcrtial  coordiaate  iyiton-origin  1*  il  Body^flicd  ccwrdiiiitt  ijrtwi  origin  b 

center  of  central  qjbere,  (hit  coordinate  *  center  of  txrml  iphert,  thij  coordinate 

wy^+m  wtimm  m  ifiwti.l  lyftBCl  tOMe*  With  SIMSAT. 


Attitwk  Ante*— dcaaibc  the  angular 
orientation  of  SIMSAT: 

Roll  =  rotation  angle  aboul  die  bj  nil 
Yaw  =  rotation  angle  about  Iheli  axil 
Filch  -  rotation  angle  about  the  bj  nil 


Figure  B.l  SIMSAT  with  Axes 

B.6  Identify  Relevant  Forces  and  Moments 

As  stated  in  the  list  of  assumptions,  there  were  no  external  forces  modeled  within 
the  system.  The  resultant  force  due  to  gravity  acts  in  a  downward  direction  at  the  center 
of  mass  of  SIMSAT .  The  resultant  upward  force  generated  by  the  air  bearing  effectively 
negates  this  gravitational  force. 

There  are  only  four  rotations  which  affect  the  angular  momentum  of  SIMSAT.  First, 
there  is  the  rotation  of  SIMSAT  about  the  inertial  origin.  The  remaining  three  rotations 
are  due  to  each  momentum  wheel  having  its  own  rotation  with  respect  to  its  center  of 
mass. 


B.7  Fundamental  Equations 

To  develop  the  proper  equations  of  motion,  the  first  step  was  identifying  which  fun¬ 
damental  laws  to  use.  No  translational  movement  was  anticipated  due  to  the  design  char¬ 
acteristics.  Therefore,  rotational  motion  was  the  only  concern  when  modeling  the  system. 
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Following  the  general  theory  of  kinematics  for  a  rigid  body,  the  vector  relationship 
shown  below  was  used  as  the  starting  point: 

M°  =  H°  (B.l) 

This  equation  states  the  force  moment,  M°,  about  a  given  point  (o  denotes  the  origin) 
equals  the  time  rate  of  change  of  the  angular  momentum  of  a  system,  H°.  [31:56] 

The  angular  momentum,  H,  of  a  body  is  a  product  of  its  inertia  matrix  and  the 
angular  velocity  vector  with  which  it  rotates  about  a  defined  point  in  space. 

H  =  Iu  (B.2) 

In  the  design,  the  total  angular  momentum  of  the  system  is  comprised  of  four  compo¬ 
nents.  The  first  segment,  SIMS AT s  body,  rotates  about  the  origin.  The  remaining  three 


components  are  due  to  the  rotations  of  the  momentum  wheels. 

H  =  Hsimsat  +  Hwi  +  Hw  2  +  Hw  3  (B.3) 

The  four  components  can  be  expressed,  in  terms  of  the  b  frame,  as: 

Hsimsat  =bnomPb“b/  (B.4) 

Hw  1  =6  JrM'1  +  ChddJ%ldLoZ\'b  (B.5) 

Hw 2  =6  J°2bub/  +  C»ff< (B-6) 
Hw 3  =6  +  CbhhJ™!huZf  (B.7) 
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b  I  comp  represents  the  inertia  matrix  of  SIMS  AT  defined  about  the  origin  in  the  b  basis. 
SIMS AT  s  angular  velocity  vector,  bub’1,  relates  the  motion  of  the  SIMS  AT  body  with 
respect  to  inertial  space.  The  different  inertia  matrices  of  the  three  momentum  wheels 
are  expressed  in  two  different  fashions.  First,  they  are  defined  with  respect  to  SIMSATs 
physical  center  using  the  b  basis,  shown  as  bJ^.  Also,  they  are  written  with  respect  to 
their  own  centers  of  mass  using  their  specific  bases  (d,  f,  and  h),  shown  as  (d>fA)  j®?.  The 
angular  velocity  vector  for  each  momentum  wheel,  is  expressed  as  its  relative 

motion  with  respect  to  SIMSATs  body  using  the  proper  basis  (d,  f,  or  h,  depending  on 
the  wheel).  Finally,  the  C  matrices  represent  necessary  transformation  matrices  to  express 
the  different  angular  momentum  components  in  a  common  basis,  the  b  basis. 

Having  these  expressions  for  the  angular  momentum  of  the  system,  the  next  logical 
step  was  calculating  H  to  find  the  torque  equation.  Since  the  angular  momentum  is  a 
vector  quantity,  it  was  necessary  to  use  the  vector  derivative  form: 

T  =  H=  4~ H  +6  ub/  x  H  (B.8) 

dt  s 

Since  the  system  has  no  external  torques,  T  disappears  to  yield 

4- H  +b  J/  x  H  =  0  (B.9) 

dt 

Following  several  steps,  the  final  expression  to  be  used  as  the  plant  model  is 


bub/  =  [bIcs  -b  Jcm  -b  J%2  -  W*,]"1  *  [CbddJ%lduiWl,b  +  ChffJgfch***  +  CbhhJ%hu3u*'b 
+b  ub/  x6  Icbub/  +b  ub/  xb  J^bub/  +b  ub/  x  CbddJ%ldJf'b  +6  ub/  x6  J^bub/ 

+bub/  x  cb"j%fuf’b  +b0Jb/  xb  J*bub/  +b  L0b/  x  CbhhJ$hu>f’b]  (B.10) 
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This  expression  relates  the  motion  of  SIMS  AT  to  the  motion  of  the  three  momentum 
wheels.  Using  this  system  of  equations,  along  with  a  motor  model  which  related  out¬ 
put  motor  torque  as  a  function  of  motor  speed,  a  variable  step  Runge-Kutta  numerical 
integration  technique  was  used  to  calculate  SIMSATs  angular  velocities. 

However,  direct  numerical  integration  could  not  be  used  to  calculate  SIMSATs  an¬ 
gular  position  since  the  equations  of  motion  were  derived  for  the  body  fixed  basis.  Since 
this  axis  system  rotates  with  SIMS  AT,  orientation  information  could  not  be  obtained  using 
this  basis.  In  order  to  correctly  express  angular  position  as  a  function  of  SIMSATs  angular 
velocity  with  respect  to  the  inertial  reference  frame,  Euler  rotations  were  employed.  The 
following  equation  shows  the  relationship  between  the  attitude  angle,  9,  and  the  angular 
velocity,  bu)bs’1,  of  a  given  body  using  a  transformation  matrix  Crot- 


Crot  *b0Jb/ 


(B.ll) 


To  specify  the  proper  rotations,  the  first  step  was  defining  the  roll,  yaw,  and  pitch 
axes  with  respect  to  the  b  basis.  The  bl  axis  was  defined  as  the  roll  axis.  About  this 
axis,  SIMS  AT  had  full  rotational  freedom.  The  b2  axis  corresponded  to  the  yaw  axis.  As 
with  the  previous  case,  SIMSAT  had  full  rotational  freedom  about  the  b2  axis.  The  pitch 
axis,  defined  as  the  b3  axis,  had  a  limitation  of  ±25  degrees  due  to  the  presence  of  the  air 
bearing  pedestal. 

Next,  the  correct  sequence  of  rotations  had  to  be  selected.  For  any  given  change 
in  orientation,  there  are  twelve  possible  rotation  sequences  which  can  be  used  [28:28]. 
However,  due  to  the  possible  points  of  singularity  for  a  defined  sequence,  the  order  of 
rotations  about  the  roll,  yaw,  and  pitch  axes  must  be  chosen  carefully. 

To  avoid  the  singularity,  the  roll-pitch-yaw  (1-3-2)  rotation  sequence  was  chosen.  The 
composite  transformation  matrix  assumed  the  form  [28:28]: 


J rot 


1  COS^Oroii^tCLTliOpifch)  siTl(^Oron^t(lTlOpifcfi) 
0  cosjftro  u)  -sin(Oroll) 

cos0  pitch)  COS  [6  pitch) 

0  sin(9rou)  cos{9roii ) 
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By  choosing  this  sequence,  the  terms  in  the  denominator  can  only  be  zero  if  the  pitch  angle 
is  90  degrees.  As  stated  before,  the  pitch  angle  is  limited  to  ±25  degrees.  Therefore,  a 
singularity  never  occurs  and  the  orientation  angles  can  be  calculated. 

To  calculate  or  measure  the  quantities  represented  by  the  different  variables,  several 
steps  occur.  While  the  angular  velocity  components  are  simply  measured  quantities  from 
the  gyro  or  the  wheel  motor,  computing  the  inertia  matrices  for  the  SIMS  AT  body  and  the 
momentum  wheels  required  several  mathematical  manipulations.  The  process  listed  below 
was  used  to  find  the  SIMS  AT  inertia  matrix,  known  as  I  comp  in  the  MATLAB  code.  As 
part  of  the  intermediate  steps,  the  inertia  matrices  for  the  momentum  wheels  in  various 
forms  were  also  calculated. 

1.  Use  simple  geometric  bodies  to  approximate  SIMS. AT s  components. 

2.  Orientation  of  each  object  has  to  be  rotated  using  transformation  matrices. 

3.  SIMSATs  center  of  mass  is  adjusted,  using  counterweights,  to  be  co-located  with 

SIMS AT s  physical  center  resting  on  the  origin. 

4.  Using  the  parallel  axis  theorem,  the  component  inertia  matrices  are  expressed  about 

SIMSATs  center  of  mass. 

The  first  step,  modeling  the  components  as  simple  geometric  bodies  with  uniform 
densities,  simplified  the  problem  to  a  manageable  level.  The  SIMSAT  vehicle  is  comprised 
of  19  components.  Connectors,  such  as  bolts  and  clamps,  were  not  modeled  due  to  the 
realization  that  the  model  exists  as  an  approximation  of  the  actual  SIMSAT  body  and 
is  not  perfect.  As  a  compromise,  the  masses  of  these  connectors  were  added  to  the  com¬ 
ponents  with  which  they  were  associated.  It  was  understood  that  the  inertia  of  these 
components  would  not  be  captured.  Additionally,  the  wiring  between  components  was  ne¬ 
glected.  Table  B.l  includes  the  breakout  of  components  and  what  shape  they  were  modeled 
as.  MATLAB  was  used  to  calculate  the  inertia  matrix. 

Once  the  proper  shapes  were  selected,  the  next  step  involved  orienting  each  com¬ 
ponent  on  the  SIMSAT  vehicle.  Initially,  all  components  were  aligned  with  the  ul  axis 
pointing  to  the  right,  the  u2  axis  pointing  up,  and  the  u3  axis  pointing  out  of  the  page. 
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Table  B.l  SIMSAT  Components 


Component 

Qty 

Geometric  Shape 

Autobox 

1 

Rectangular  Parallelpiped 

Mounting  Disk 

2 

Rectangular  Parallelpiped 

Battery 

1 

Rectangular  Parallelpiped 

Mounting  Shafts 

2 

Right  Circ.  Cylinder 

Central  Sphere 

1 

Sphere 

Counterweight  Mechanism 

1 

Right  Circ.  Cylinder 

Gyro 

4 

Rectangular  Parallelpiped 

Momentum  Wheel 

Right  Circ.  Cylinder 

Motor 

3 

Rectangular  Parallelpiped 

Transmitter/Receiver 

1 

Rectangular  Parallelpiped 

The  choice  of  a  u  basis  was  consistent  with  Kramer  [31: Appendix  D]  to  represent  the 
component’s  own  axes.  Please  refer  to  Figure  B.2  for  the  geometric  shapes  and  their  axes. 

In  order  to  express  SIMSATs  components  in  a  common  basis  (the  b  basis),  trans¬ 
formation  matrices  were  developed  for  each  component.  This  method  provided  additional 
flexibility  when  determining  location  and  orientation  of  each  item.  The  other  alternative, 
fixing  a  component’s  dimensions  to  match  the  orientation  with  respect  to  the  b  basis, 
proved  more  difficult  when  changing  the  mechanism’s  alignment. 

Each  transformation  matrix  used  a  1-2-3  rotation  sequence.  While  most  components 
were  only  subject  to  one  rotation  of  90  degrees,  the  full  capability  of  the  three  rotation 
sequence  was  used  to  increase  flexibility  during  the  detailed  design  phase. 


Rota  = 


c(62)c{0 3)  c(0i)s(03)  +  s(0i)s(02)c(03)  s(0i)s03)  -  c(0i)s(02) 

-c(02)s(03)  c(01)c(03)  -  s(0i)s(02)s(03)  s(0i)c(03)  +  c(0i)s(02) 

s(e2)  s(6  i)c(02)  c(0i)c(02) 


Mathematically,  to  change  from  one  basis  to  another,  a  given  matrix  needs  to  be  multiplied 
by  both  the  rotation  matrix  and  the  rotation  matrix’s  transpose.  This  ensures  multipli¬ 
cation  by  the  equivalent  of  an  identity  matrix  to  maintain  the  values  within  the  original 
matrix. 
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Figure  B.2  Geometric  Shapes 


hattb  =  Cub  *  hattu  *  CuhT  (B.12) 

For  the  nominal  design,  the  rotations  listed  in  Table  B.2  were  used  for  the  different  com¬ 
ponents. 

Following  the  rotations,  the  next  phase  was  locating  the  composite  center  of  mass 
for  the  SIM  SAT  body.  The  goal  was  aligning  the  composite  center  of  mass  as  close  to  the 
origin  as  possible  through  the  use  of  weight  plates  and  the  counterweight  mechanism. 

The  first  step  involved  calculating  the  mass  difference  between  the  two  sides.  Weight 
plates  were  added  to  the  lighter  side  until  the  system  was  balanced.  In  order  to  place  the 
weight  plates  properly  to  adjust  the  center  of  mass  to  the  origin,  the  following  technique 
was  used.  (Please  refer  to  Figure  B.3  throughout  this  discussion). 

Within  the  confines  of  the  design  problem,  the  position  vector  of  each  component 
was  measured  from  the  physical  center  of  SIMS  AT  (which  rests  at  the  origin).  The  center 
of  mass  of  SIMS  AT,  point  c,  represents  a  point  which  will  most  likely  be  located  away 
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Table  B.2  Component  Rotation  Angles 


Component 

Theta  1 

Theta  2 

Theta  3 

Autobox 

90 

0 

0 

Battery 

0 

90 

90 

Mounting  Shaft  1 

0 

0 

90 

Mounting  Shaft  2 

0 

0 

-90 

Central  Sphere 

0 

0 

0 

Gyro  1 

0 

0 

90 

Gyro  2 

0 

0 

0 

Gyro  3 

-90 

0 

0 

Gyro  4 

45 

45 

45 

Momentum  Wheel  1 

0 

0 

90 

Momentum  Wheel  2 

0 

0 

0 

Momentum  Wheel  3 

-90 

0 

0 

Motor  1 

0 

0 

90 

Motor  2 

0 

0 

0 

Motor  3 

-90 

0 

0 

Transmit  ter  /  Receiver 

0 

0 

90 

from  the  origin.  The  distance  between  these  two  points  represents  the  delta  which  the 
counterweight  was  designed  to  remove. 

In  general,  the  position  vector  of  the  center  of  mass  can  be  expressed  as 


En 

_  i= 1 


mi  rpi 


m 


(B.13) 


where  °rc  represents  the  position  of  the  center  of  mass  with  respect  to  the  origin.  The 
summation  includes  all  components  of  SIMS  AT.  The  mass  in  the  denominator  denotes  the 
total  mass  of  the  system. 

To  solve  for  the  position  vector  of  the  counterweight,  the  equation  was  rewritten  as: 

orc  _  sr=l  [mi  *°  rpi]  ~h  mcw  *°  rcw  '  (g 

m 
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Component  1 


Figure  B.3  Center  of  Mass  for  Multiple  Components 

The  goal  at  this  point  was  to  eliminate  the  distance  between  the  center  of  mass  and  the 
origin.  Therefore,  °rc  equals  the  zero  vector.  To  do  this,  the  expression  in  the  numerator 
must  equal  zero. 


n 

Y2imi  *°  rpi\  +  mcw  *°  few  =  0 
i—  1 


(B.15) 


It  follows  that 


T CM)  * — 


_  -EtiK 


mc 


(B.16) 


At  this  stage,  the  center  of  mass  was  coincident  with  both  the  origin  and  physical  center 
of  SIMSAT. 
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Finally,  the  composite  inertia  matrix  was  calculated.  Despite  being  in  a  common 
basis,  the  different  components  had  to  be  expressed  about  a  common  reference  point,  the 
origin.  To  do  this,  the  parallel  axis  theorem  [56:109]  was  used. 


lorigirii 


Icorrii  d~  mcom j  * 


Ay2  +  A  Z2 
—Ax  Ay 
—AxAz 


—AyAx 
Ax2  +  Az2 
—AyAz 


—AzAx 
—AzAy 
Ax2  +  Ay 


Icorm  represents  the  inertia  matrix  of  a  given  component  with  respect  to  its  center  of  mass. 
The  mass  of  the  component  is  represented  by  mC077lt..  Within  the  matrix,  the  Ax,  Ay,  and 
Az  values  are  the  distances  between  the  component’s  center  of  mass  and  SIMS AT s  origin. 
Iorigim  represents  the  inertia  matrix  of  the  component  about  the  origin.  Once  the  inertia 
matrices  were  adjusted  to  be  expressed  with  respect  to  the  origin,  they  were  simply  added 
together.  The  final  expression  was  Icomp,  the  inertia  of  the  SIMSAT  body,  including  all 
components.  The  values  within  this  matrix  were  considered  constant  throughout  a  given 
experiment. 


Icomp  —  ^  '\I origin,] 
i= 1 


(B.17) 


B-13 


Appendix  C.  Momentum  Wheel  Sizing 

C.l  Momemtum  Wheel  Development 

Once  the  SIMS  AT  equations  of  motion  had  been  developed  and  coded  into  a  MAT- 
LAB  computer  program,  the  team  focused  on  momentum  wheel  design.  Momentum  wheel 
development  was  clearly  a  system  driver,  and  early  resolution  of  wheel  issues  was  critical 
for  the  subsequent  development  of  other  subsystems. 

C.1.1  Location  of  Components.  To  analyze  the  effects  of  various  wheel 
designs  on  SIMS  AT  motion,  a  nominal  “best  guess”  configuration  for  SIMS AT  was  selected. 
Although  the  final  appearance  of  SIMS  AT  was  not  yet  known,  the  salient  characteristics 
of  competing  wheel  designs  could  still  be  compared.  Figure  C.l  and  Table  C.l  show  a 
listing  of  individual  components,  masses,  dimensions,  and  position  vectors  from  the  inertial 
origin  (the  center  of  the  central  sphere)  to  the  center  of  gravity  (c.g.)  of  each  component. 
At  this  point  in  the  design,  only  the  masses  and  dimensions  of  the  battery,  AutoBox, 
model  helicopter  (Horizon)  gyroscopes,  SmartMotor,  central  sphere,  mounting  shafts,  and 
mounting  disks  were  known.  The  mass  and  dimensions  of  the  transmit  ter /receiver  were 
estimated  from  vendor  catalogs,  and  the  parameters  of  the  momentum  wheels  were  left  as 
design  variables. 

The  counterweight  was  a  notional  object  used  to  balance  SIMS  AT  in  the  MATLAB 
computer  simulation.  The  counterweight  was  modeled  as  a  right  circular  cylinder  with  15 
cm  radius  and  7  cm  height.  The  mass  of  the  counterweight  was  calculated  as  the  mass  dif¬ 
ference  between  the  positive  ‘bi’  side  components  (3  motors,  3  momentum  wheels,  4  gyros, 
1  battery)  and  the  negative  ‘bi’  side  components  (Autobox  and  transmitter/receiver).  The 
center  of  mass  of  the  counterweight  was  placed  at  a  position  vector  that  balanced  SIMS  AT 
(i.e.,  the  overall  system  center-of-gravity  was  located  at  [0,  0,  0]  of  the  body  coordinate 
system  at  time  t=0).  Mathematically,  the  counterweight’s  position  vector  was  calculated 
from: 
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Inertial  coordinate  system-origin  is  at 
center  of  central  sphere,  this  coordinate 
system  remains  fixed  in  inertial  space 


Body-fixed  coordinate  system-origin  is 
at  center  of  central  sphere,  this  coordinate 
system  rotates  with  SIMS  AT. 


Attitude  Angles— describe  the  angular 
orientation  of  SIMS  AT: 

Roll = rotation  angle  about  the  bj  axis 
Yaw = rotation  angle  about  the  axis 
Pitch = rotation  angle  about  the  b3  axis 


Figure  C.l  Nominal  Configuration  Used  for  Momentum  Wheel  Design 
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Table  C.l  Nominal  Configuration  Component  Properties 


Nominal  S1MSAT  Components  used  for  Momentum  Wheel  Design 


Item  Mass  Dimensions  Position  Vector 


(kg) _ (cm) _ (from  origin  to  item’s  c.g.  in  cm) 


Sphere 

7.6 

radius  =  1 1 

[0,  0,  0] 

Mt.  Shaft  1 

0.855 

radius  =  4,  height  =  13 

[17.5,  0,  0] 

Mt  Shaft  2 

0.855 

radius  =  4,  height  =  13 

[-17.5,0,0] 

Mt.  Disk  1 

4.845 

radius  =  15,  height  =  5.1 

[26.55,  0,  0] 

Mt.  Disk  2 

4.845 

radius  =  15,  height  =  5.1 

[-26.55,  0,  0] 

Motor  1 

3.635 

15*8*8 

[50.1,0,  0] 

Motor  2 

3.635 

8*15*8 

[43.6,  0,  25.5] 

Motor  3 

3.635 

8*8*15 

[41 .6,  23.5,  0] 

Wheell 

Design  Variable 

Design  Variables 

[71.1,0,0] 

Whee!2 

Design  Variable 

Design  Variables 

[43.6,  0,  46.5] 

Wheel3 

Design  Variable 

Design  Variables 

[41 .6,  44.5,  0] 

Battery 

20 

16.7*7.6*18.1 

[37.9,  -23.35,  0] 

Gyro  1 

0.05 

2.65*4.65*4.25 

[36,0,  -11] 

Gyro  2 

0.05 

4.65*2.65*4.25 

[35,  0,  2] 

Gyro  3 

0.05 

4.65*4.25*2.65 

[36,  11,0] 

Gyro  4 

0.05 

same  as  gyro  2  but  rotated 

45°about  each  'b"  axis 

[36,  5,  5] 

Autobox 

8.6. 

19.5*44*20 

[-43.85,0,  -25] 

Xmit/Rec 

2.2 

8.2*15*5.2 

[-36.7,  -35.8,  0] 

Counterwt 

Varies  to  balance  SimSat 

radius  =  15,  height  =  7 

Varies  to  balance  SimSat 

Notes: 

1 .  Dimensions  are  given  as  length  in  b ,  direction  *  width  in  b2  direction  *  depth  in  b3  direction 

2.  Position  vectors  are  in  the  body  reference  frame  [^  vector  component,  b2  vector  component,  fc>3  vector  component] 

3.  Coordinate  origin  is  at  center  of  central  sphere 
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where 


*  Ei=i  "W 

rcomp  —19 


(C.1) 


rComp  —  position  vector  from  the  origin  to  the  composite  center  of  mass  of  the  system 
mi  =  mass  of  the  ith  component 

r‘i  =  position  vector  from  the  origin  to  the  c.g.  of  the  ith  component 
For  a  balanced  system,  rcomp  —  [0,  0,  0].  Solving  for  rcw  to  balance  the  system: 


*  -  Ll=i  mn 

rcw  — 

m cw 

where 

fcw  =  position  vector  from  the  origin  to  the  c.g.  of  the  counterweight 
mcw  =  mass  of  the  counterweight 


(C.2) 


C.1.2  Estimating  Motor  Torque.  The  torque  characteristics  of  the  3450 
series  SmartMotor  needed  to  be  estimated  before  computer  simulation  of  SIMS  A  T  motion 
could  begin.  The  manufacturer  of  the  SmartMotor,  Animatics  Corporation,  supplied  a 
Torque  vs.  Motor  speed  graph  that  displays  peak  and  continuous  performance  at  48V 
(see  Figure  C.2).  Although  the  3450  motor  is  capable  of  operating  up  to  the  peak  torque 
curve,  the  operating  duration  in  this  region  is  limited.  Sustained  operation  at  peak  torque 
heavily  taxes  the  motor  and  is  inefficient  because  significant  motor  power  is  lost  as  heat. 

For  a  fast  SIMS  AT  slewing  (yaw)  maneuver,  it  was  conservatively  assumed  the  mo¬ 
tor  would  be  operated  at  its  maximum  continuous  torque  capability.  For  incorporation 
into  a  MATLAB  simulation,  the  manufacturer’s  maximum  continuous  torque  curve  was 
approximated  with  an  exponential  curvefit.  At  this  point  in  the  SIMS  AT  design  process, 
a  24V  and  a  36V  electrical  bus  were  still  being  considered  as  possible  options.  Therefore, 
the  manufacturer’s  torque  curve  needed  to  be  scaled  down  from  48V  to  36V  and  24V  for 
performance  analysis.  If  it  is  assumed  that  power  input  to  the  motor  is  roughly  equal  to 
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Speed  (kRPM) 


Figure  C.2  Animatics  SmartMotor  Torque  vs.  Motor  Speed  Curves 

power  output  of  the  motor,  then  a  36V  torque  curve  (with  amperage  held  constant)  is  a 
75%  scaling  of  the  48V  curve,  similarly,  a  24V  curve  is  a  50%  scaling. 

The  manufacturer’s  48V  torque  curve  was  approximated  with: 

T(w)  =  250  -  e0-00162w 
where 

T—  Torque  (in  ounce-inches) 

oj=  motor  speed  (in  revolutions  per  minute) 

After  converting  from  English  units  to  metric  units,  a  36V  torque  curve  was  mathematically 
approximated  with: 

T(w)  =  0 .00706 1  *  ( 1 88-e00 193942w ) 
where 

T  =  Torque  (in  Newton-meters) 
u>  =  motor  speed  (in  radians/second) 

A  24V  torque  curve  was  approximated  with: 

T(u)  =  .007061*(125-e0  0271251a;) 


C-5 


C.1.3  Design  Groundrules.  Before  analysis  of  different  momentum  wheel 
designs  could  begin,  a  performance  criterion  was  needed  to  assess  competing  designs.  Dis¬ 
cussions  with  the  SIMS  AT  customers  revealed  that  maximizing  slew  (yaw)  rate  for  a  10 
second  maneuver  was  an  important  goal.  For  an  initial  design  and  to  simplify  analysis, 
the  customers  also  stated  that  orienting  three  momentum  wheels  orthogonal  to  each  other 
was  an  acceptable  way  of  providing  motion  input  to  SIMS  AT. 

Theoretically,  a  non-orthogonal  arrangement  of  momentum  wheels  (i.e.,  using  more 
than  three  wheels  or  not  orienting  three  wheels  orthogonal  to  each  other)  could  possibly 
improve  motion  performance.  However,  a  non-orthogonal  arrangement  complicates  the 
analysis  of  attitude  control  and  dynamics,  and  an  untraditional  momentum  wheel  orienta¬ 
tion  could  create  structural  mounting  challenges.  Also,  optimization  of  one  subsystem  can 
penalize  the  overall  system.  For  instance,  the  time  spent  optimizing  the  momentum  wheel 
arrangement  could  have  created  a  schedule  delay  for  the  final  design  of  the  entire  SIMS  AT 
system. 

Orthogonal  momentum  wheels  still  did  not  change  the  coupled  inertia  properties 
of  SIMSAT.  The  different  masses  and  shapes  of  SIMSATs  components  made  the  overall 
system  an  asymmetric  body  with  products  of  inertia  (off-diagonal  terms)  in  its  inertia 
matrix.  These  products  of  inertia  created  a  coupling  effect  so  that  when  a  torque  was 
applied  to  one  axis,  motion  resulted  in  the  other  two  axes  as  well.  However,  MATLAB 
simulations  using  the  nominal  SIMSAT  configuration  revealed  that  a  one  axis  input  torque 
resulted  in  motion  primarily  about  that  same  axis.  For  instance,  a  motor  #2  input  torque 
about  an  axis  parallel  to  the  b2  axis  (see  Figure  ??)  caused  significant  SIMSAT  yaw  motion 
(in  the  direction  opposite  than  the  input  torque).  Because  of  the  inertia  coupling,  roll  and 
pitch  motion  also  occurred,  but  to  a  lesser  degree  than  the  yaw  motion. 

Since  the  SIMSAT  roll  axis  (‘bi’  axis  in  Figure  ??)  had  the  smallest  moment  of 
inertia,  the  idea  of  making  wheel  #1  smaller  and  lighter  than  the  other  two  wheels  was 
considered.  If  a  high  roll  rate  was  not  important  to  a  customer,  a  lower  performance  roll 
axis  momentum  wheel  might  be  acceptable.  However,  the  customers’  desire  was  to  make 
all  three  momentum  wheels  identical. 
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C.1.4  Initial  Wheel  Analysis.  With  the  design  ground-rules  established, 
momentum  wheels  of  different  sizes,  shapes,  and  metal  composition  were  analyzed  via 
MATLAB  computer  simulation.  Aluminum  and  steel  designs  were  compared  because  both 
metals  were  readily  available  and  could  be  easily  machined  by  the  AFIT  fabrication  shop. 

To  compare  the  10  second  yaw  performance  of  various  wheel  designs,  a  simulated 
open-loop  “bang-bang”  control  input  was  assumed.  The  yaw  axis  SmartMotor  (modeled 
using  the  T(w)  equations  describe  earlier)  applied  a  maximum  continuous  positive  torque 
to  one  momentum  wheel  for  the  first  five  seconds,  and  a  maximum  continuous  negative 
torque  to  the  same  wheel  for  the  last  five  seconds.  As  a  result,  this  simulated  momentum 
wheel  was  accelerated  for  the  first  five  seconds  and  decelerated  for  seconds  5  through  10. 
The  intended  effect  of  this  simulated  maneuver  was  to  have  SIMS  A  T  start  at  rest  at  time 
t  =  0  seconds,  yaw,  and  end  at  rest  at  time  t  =  10  seconds. 

For  a  real-world  open-loop  “bang-bang”  scenario,  input-shaping  of  the  current  (am¬ 
peres)  supplied  to  the  motor  would  need  to  occur.  This  input-shaping  would  force  the 
motor  to  accelerate  along  its  maximum  continuous  torque  curve  for  the  first  five  seconds 
and  then  decelerate  along  this  curve  for  the  last  five  seconds.  Although  this  open-loop  ap¬ 
proach  would  probably  never  be  used  to  control  the  real-world  SIMS  AT,  such  an  approach 
was  conducive  to  computer  simulation  for  momentum  wheel  sizing. 

To  simplify  momentum  wheel  analysis,  the  roll  and  pitch  axis  motors  (motors  #1  and 
#3)  received  zero  torque  during  the  computer  simulations.  Even  though  the  roll  and  pitch 
wheels  remained  motionless,  SIMSAT  still  displayed  some  roll  and  pitch  motion  because 
of  the  inertia  coupling  effects  explained  earlier. 

The  first  set  of  computer  simulations  compared  aluminum  and  steel  solid  disk  wheels. 
The  radius  and  thickness  of  the  solid  disks  were  varied  to  determine  the  effect  on  SIMSAT 
yaw  performance.  Table  C.2  summarize  these  solid  disk  designs.  The  terminology  and 
assumptions  used  in  Table  C.2  are  defined  as  follows: 

•  Motorl/Wheell  -  oriented  parallel  to  the  roll  axis,  used  to  provide  torque  input 

primarily  to  the  roll  axis. 
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Table  C.2 


Aluminum  and  Steel  Solid  Disk  Wheels 


Momentum  Wheel  Analysis  (with  all  three  wheels  identical  size) 
for  Wheel  #2 

Solid  Disk 


lAluminum  (density  =  2.8  g/cc) 


Max  wheel  Yaw  rate  Yaw  angle  Slew  rate 


radius 

radius 

thickness 

thickness 

Wheel  mass 

CW  mass 

speed 

at  5  sec 

at  1 0  sec 

10  sec  avg 

(inches) 

(cm) 

(inches) 

(cm) 

(kg) 

<ib) 

(kg) 

(rad/sec) 

(rad/sec) 

(rad) 

(deg/sec) 

8 

20.32 

1 

2.54 

9.23 

20.306 

47.98 

35 

0.8565 

4.91 

6 

15.24 

1 

2.54 

5.19 

11.418 

35.87 

110  . 

0.23 

1.1941 

6.84 

4 

10.16 

1 

2.54 

2.31 

5.082 

27.22 

270 

0.16 

1.2056 

6.91 

3 

7.62 

1 

2.54 

1.3 

2.86 

24.2 

saturates 

0.06 

2.06 

8 

20.32 

2 

5.08 

18.45 

40.59 

75.66 

17 

0.12 

0.5263 

3.02 

6 

15.24 

2 

5.08 

10.38 

22.836 

51.44 

55 

0.16 

0.8 

4.58 

4 

10.16 

2 

5.08 

4.61 

10.142 

34.14 

240 

0.22 

1.2069 

6.92 

3 

7.62 

2 

5.08 

2.59 

5.698 

28.09 

270 

0.1 

0.8232 

4.72 

4 

3 

7.62 

6.92 

15.224 

41.06 

175 

0.19 

1.0141 

5.81 

2 

5.08 

3 

7.62 

1.73 

3.806 

25.49 

saturates 

0.03 

0.19 

1.09 

|steel  (density 

=  7.85  g / 

cc) 

Max  wheel 

Yaw  rate 

Yaw  angle 

Slew  rate 

radius 

radius 

thickness 

thickness 

Wheel  mass 

CW  mass 

speed 

at  5  sec 

at  1 0  sec 

10  sec  avg 

(inches) 

..(cm) 

(inches) 

(cm) 

(kg) 

(lb) 

(kg) 

(rad/sec) 

(rad/sec) 

(rad) 

(deg/sec) 

8 

20.32 

1 

2.54 

25.86 

56.892 

97.9 

10 

0.08 

0.4027 

2.31 

6 

15.24 

1 

2.54 

14.55 

32.01 

63.95 

40 

0.13 

0.6345 

3.64 

4 

10.16 

1 

2.54 

6.47 

14.234 

39.7 

90 

0.21 

1.05 

6.02 

3 

7.62 

1 

2.54 

3.64 

8.008 

31.22 

270 

0.12 

0.9382 

5.38 

2 

5.08 

1 

2.54 

1.62 

3.564 

25.15 

saturates 

0.03 

0.19 

1.09 

4 

10.16 

2 

5.08 

12.93 

28.446 

59.1 

100 

0.13 

0.6919 

3.96 

3 

7.62 

2 

5.08 

7.27 

15.994 

41.13 

250 

0.17 

0.9262 

5.31 

2 

5.08 

2 

5.08 

3.233 

7.1126 

30 

saturates 

0.05 

0.34 

1.95 

2 

5.08 

3 

7.62 

4.85 

10.67 

34.85 

270 

0.06 

0.5207 

2.98 

2 

5.08 

4 

10.16 

6.47 

14.234 

39.7 

270 

0.07 

0.595 

3.41 

Notes: 


1.  Initial  conditions:  all  three  momentum  wheels  at  rest,  SimSat  at  rest,  all  euler  angles  zero 

2.  Positive  bt  side  -  motors,  momentum  wheels,  battery,  4  gyros 

3.  Negative  b,  side  -  Autobox,  xm it/receiver,  counterweight 

4.  Max  allowable  wheel  speed  =  270  rad/sec  (2600  rpm) 

5.  Simulation  run  for  10  seconds 

6.  Max  continuous  torque  curve  applied  to  motor  #2  for  first  5  seconds, 

torque  reversed  to  motor  #2  for  seconds  5  through  10  (motors  #1  &  #3  motionless) 

7.  Effect  of  a  wheel  axle  is  ignored 

8.  36  volts  (simulated)  applied  to  motor  #2 
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•  Motor2/Wheel2  -  oriented  parallel  to  the  yaw  axis,  used  to  provide  torque  input 
primarily  to  the  yaw  axis. 

•  Motor3/Wheel3  -  oriented  parallel  to  the  pitch  axis,  used  to  provide  torque  input 
primarily  to  the  pitch  axis. 

•  CW  mass  -  counterweight  mass  necessary  to  balance  SIMS  AT  in  the  simulation. 

•  Saturation  -  when  a  simulated  momentum  wheel  exceeds  the  maximum  speed  ca¬ 
pability  of  the  SmartMotor  in  a  10  second  maneuver.  Wheels  that  are  too  small  or 
light  lack  inertia  storage  capability  and  tend  to  saturate. 

•  Yaw  Rate  at  5  Seconds  -  the  maximum  instantaneous  yaw  rate;  occurs  at  the  t  =  5 
second  point  in  the  maneuver,  measured  in  radians/second. 

•  Yaw  Angle  at  10  Seconds  -  the  final  SIMS  AT  yaw  angle  after  a  10  second  maneuver 
from  rest  (starting  with  zero  yaw  angle),  measured  in  radians. 

•  10  Second  Average  Slew  Rate  -  the  primary  criterion  used  to  compare  momentum 
wheel  designs,  defined  as  the  final  SIMSAT  yaw  angle  (in  degrees)  divided  by  10 
seconds. 

•  Since  a  wheel  axle’s  inertia  is  small  in  relation  to  the  entire  wheel,  all  wheels  were 
modeled  without  axles. 

From  Table  C.2,  it  can  be  seen  that  aluminum  designs,  in  general,  give  higher  yaw 
performance  than  steel  designs.  Because  of  the  distance  of  the  momentum  wheel  from 
the  SIMSAT  origin,  a  dense  object,  such  as  a  solid  steel  disk,  creates  more  of  a  system 
inertia  penalty  than  an  object  of  lesser  density  .  However,  solid  steel  wheels  are  less  likely 
to  saturate  than  their  aluminum  counterparts.  The  higher  density  of  steel  gives  it  more 
inertia  storage  capability  than  aluminum.  Since  wheel  inertia  properties  are  dictated  by 
mass  and  area,  aluminum  and  steel  designs  with  small  radii  and/or  thicknesses  also  tended 
to  saturate. 

Figure  C.6  shows  a  solid  disk  wheel  (as  well  as  the  other  wheel  shapes  that  were  analyzed). 

MATLAB  output  graphs  from  a  typical  simulation  (solid  aluminum  disk  wheel  with 
6”  radius  and  1”  thick)  are  shown  in  Figure  C.7,  Figure  C.8  and  Figure  C.9. 
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Solid  Disk 


6-holed  Wheel  Theoretical  Hoop 


Figure  C.6  Momentum  Wheel  Shapes 


Momentum  Wheel  Speeds  vs.  Time:  Wl(solid),  W2(dashed),  W3(dotted) 
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Figure  C.7  Momentum  Wheel  Speeds 


Simsat  Rollrate(solid),  Yawrate(dashed),  Pitchrate(dotted)  vs.  Tima 
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Figure  C. 8  SIMSAT  Angular  Velocities 


Roll  Angle(soltd),  Yaw  Angle(dashed),  and  Pitch  Angle(dotted)  vs.  Time 
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Figure  C.9  SIMSAT  Euler  Angles 


To  simulate  a  “wheel-and-spoke”  configuration,  aluminum  and  steel  disks  with  six 
holes  were  also  examined  (see  Table  C.3).  Because  mass  was  removed  from  the  solid  wheel 
face,  the  six-holed  wheels  performed  better  than  their  solid  disk  counterparts.  With  few 
exceptions,  the  aluminum  designs  outperformed  the  steel  designs. 

“Theoretical”  hoop-shaped  momentum  wheels  were  also  analyzed.  Although  a  pure 
hoop  without  spokes  is  not  physically  feasible,  the  inertia  properties  of  a  hoop  warranted 
study.  As  seen  in  Table  C.4,  hoop-shaped  wheels,  in  general,  had  better  yaw  performance 
than  solid  disks  or  six-holed  wheels.  Since  the  moment  of  inertia  of  a  wheel  is  dependent 
upon  the  square  of  its  radius,  locating  most  of  a  wheel’s  mass  near  its  circumference  (rather 
than  near  its  center)  is  beneficial. 

After  the  attractive  inertia  properties  of  the  hoop  shape  were  identified,  a  more 
detailed  analysis  of  aluminum  vs.  steel  began.  First,  hoop  width  (width  =  outer  radius 
-  inner  radius)  and  thickness  were  held  constant,  but  the  outer  radius  of  the  hoop  was 
allowed  to  vary.  The  objective  was  to  find  the  dimensions  of  an  aluminum  hoop  that 
possessed  the  same  moment  of  inertia  as  a  steel  hoop.  From  Table  C.5,  it  can  be  seen  that 
aluminum  hoops  outperformed  steel  hoops  with  the  same  inertia.  However,  the  aluminum 
wheels  were  much  larger  than  their  steel  counterparts.  This  is  noteworthy  because  trying 
to  integrate  three  large  momentum  wheels  onto  SIMS  AT  could  present  other  difficulties 
(such  as  structural  mounting). 

Next,  the  outer  radius,  moment  of  inertia,  and  thickness  of  aluminum  and  steel  hoops 
were  held  constant,  but  the  steel  hoop  width  was  allowed  to  vary.  Table  C.6  summarizes 
this  analysis.  This  table  demonstrates  that  a  steel  hoop  with  a  thin  width  outperforms  an 
aluminum  hoop  of  larger  width.  Designing  an  aluminum  hoop  with  a  thin  width,  however, 
is  not  a  preferred  solution  because  this  wheel  causes  the  motor  to  saturate  in  a  10  second 
maneuver.  A  saturated  motor  cannot  provide  any  torque  to  SIMSAT. 

C.1.5  Detailed  Wheel  Design.  From  the  preceding  analysis,  it  was 
evident  that  a  wheel  design  imitating  a  hoop  shape,  possessing  a  large  outer  radius,  and 
using  a  thin  rim  would  maximize  SIMSAT  yaw  performance.  Before  proceeding  further, 
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Table  C.3  Aluminum  and  Steel  Wheels  with  Six  Holes 


Momentum  Wheel  Analysis  (with  all  three  wheels  identical  size) 
for  Wheel  #2 

Wheel  with  6  holes 


lAluminum  (density  =  2.8  ~g/ocj~~H[ 


Outer 

radius 

(inches) 

Hoop 

width 

(inches) 

Wheel 

thickness 

(inches) 

Hole 

radius 

(inches) 

Outer 

radius 

(cm) 

Wheel 

thickness 

(cm) 

Hole 

radius 

(cm) 

Whl  mass 
(kg) 

Whl  mass 
(lb) 

Max  wheel 
speed 
(rad/sec) 

Yaw  rate 
at  5  sec 
(rad/sec) 

Yaw  angle 
at  10  sec 
(rad) 

Slew  rate 
lOsecavg 
(deg/sec) 

5 

1 

0.75 

1.25 

12.7 

1.905 

3.175 

1.6892 

3.71624 

0.25 

1.5682 

8.99 

4.5 

1 

0.75 

1.125 

11.43 

1.905 

2.8575 

1.3683 

3.01026 

270 

0.17 

1.3241 

7.59 

4 

1 

0.75 

0.875 

10.16 

1.905 

2.2225 

1.2331 

2.71282 

270 

0.12 

0.9973 

5.71 

5 

1 

1 

1.25 

12.7 

2.54 

3.175 

2.2523 

4.95506 

250 

0.27 

1.5805 

9.06 

4.5 

1 

1 

1.125 

11.43 

2.54 

2.8575 

1.8244 

4.01368 

270 

0.22 

1.4578 

8.35 

4 

1 

1 

0.875 

10.16 

2.54 

2.2225 

1.6442 

3.61724 

270 

0.15 

1.1701 

6.70 

5 

1 

1.25 

1.25 

12.7 

3.175 

3.175 

2.8154 

6.19388 

220 

0.3 

1.5157 

8.68 

4.5 

1 

1.25 

1.125 

11.43 

3.175 

2.8575 

2.2805 

5.0171 

260 

0.25 

1.4984 

8.59 

4 

1 

1.25 

0.875 

10.16 

3.175 

2.2225 

2.0552 

4.52144 

270 

0.17 

1.2741 

7.30 

|Steel  (density  -  7.85  g/cc) 


Outer 

radius 

(inches) 

Hoop 

width 

(inches) 

Wheel 

thickness 

(inches) 

Hole 

radius 

(inches) 

Outer 

radius 

(cm) 

Wheel 

thickness 

(cm) 

Hole 

radius 

(cm) 

Whl  mass 
(kg) 

Whl  mass 
(lb) 

Max  wheel 
speed 
(rad/sec) 

Yaw  rate 
at  5  sec 
(rad/sec) 

Yaw  angle 
at  1 0  sec 
(rad) 

Slew  rate 
lOsecavg 
(deg/sec) 

5 

1 

0.75 

1.25 

12.7 

1.905 

3.175 

4.7359 

10.41898 

HnQgHi 

0.24 

1.246 

7.14 

4.5 

1 

0.75 

1.125 

11.43 

1.905 

2.8575 

3.8361 

8.43942 

200 

0.26 

1.3523 

7.75 

4 

1 

0.75 

0.875 

10.16 

1.905 

2.2225 

3.4572 

7.60584 

255 

0.23 

1.3318 

7.63 

5 

1 

1 

'  1.25 

12.7 

2.54 

3.175 

6.3145 

13.8919 

105 

0.22 

1.0778 

6.18 

4.5 

1 

1 

1.125 

11.43 

2.54 

2.8575 

5.1148 

11.25256 

155 

0.23 

1.197 

6.86 

4 

1 

1 

0.875 

10.16 

2.54 

2.2225 

4.6096 

10.14112 

220 

0.23 

1.2312 

7.05 

5 

1 

1.25 

1.25 

12.7 

3.175 

3.175 

7.8932 

17.36504 

85 

0.18 

0.9498 

5.44 

4.5 

1 

1.25 

1.125 

11.43 

3.175 

2.8575 

6.3935 

14.0657 

125 

0.22 

1.0692 

6.13 

4 

1 

1.25 

0.875 

10.16 

3.175 

2.2225 

5.762 

12.6764 

185 

0.22 

1.1189 

6.41 

Notes:  1.  Initial  conditions:  all  three  momentum  wheels  at  rest,  Sim  Sat  at  rest,  all  euler  angles  zero 

2.  Positive  b,  side  -  motors,  momentum  wheels,  battery,  4  gyros 

3.  Negative  b t  side  -  Autobox,  xmit/receiver,  counterweight 

4.  Max  allowable  wheel  speed  =  270  rad/sec  (2600  rpm) 

5.  Simulation  run  for  10  seconds 

6.  Max  continuous  torque  curve  applied  to  motor  #2  for  first  5  seconds, 

torque  reversed  to  motor  #2  for  seconds  5  through  1 0  (motors  #1  &  #3  motionless) 

7.  Effect  of  a  wheel  axle  is  ignored 

8.  36  volts  (simulated)  applied  to  motor  #2 
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Table  C.4 


Theoretical  Aluminum  and  Steel  Hoop  Wheels 


Momentum  Wheel  Analysis  (with  all  three  wheels  identical  size) 
for  Wheel  #2 
Hoop  Shape 


|Aluminum 

(density  = 

2.8  g/cc)  | 

I 

Outer 

Inner 

Outer 

Inner 

Max  wheel 

Yaw  rate  Yaw  angle 

Slew  rate 

radius 

radius 

width 

height 

radius 

radius 

height 

Whl  mass  Whl  mass 

speed 

at  5  sec 

at  10  sec 

10  secavg 

(inches) 

(inches) 

(inches) 

(inches) 

(cm) 

(cm) 

(cm) 

.  (kg) 

(lb) 

(rad/sec) 

(rad/sec) 

(rad) 

(deg/sec) 

8 

7 

1 

1 

20.32 

17.78 

2.54 

2.16 

4.752 

85 

0.34 

1.7016 

9.75 

6 

5 

1 

1 

15.24 

12.7 

2.54 

1.59 

3.498 

200 

0.35 

1.8348 

10.51 

4 

3 

1 

1 

10.16 

7.62 

2.54 

1.009 

2.2198 

270 

0.14 

1.1325 

6.49 

2 

1 

1 

1 

5.08 

2.54 

2.54 

0.432 

0.9504 

saturates 

0.01 

0.1 

0.57 

8 

7 

1 

2 

20.32 

17.78 

5.08 

4.32 

9.504 

40 

0.25 

1.2903 

7.39 

6 

5 

1 

2 

15.24 

12,7 

5.08 

3.17 

6.974 

105 

0.3 

1.4883 

8.53 

4 

3 

1 

2 

1D.16 

7.62 

5.08 

2.02 

4.444 

265 

0.23 

1.4876 

8.52 

2 

1 

1 

2 

5.08 

2.54 

5.08 

0.865 

1.903 

saturates 

0.02 

0.12 

0.69 

4 

3 

1 

3 

10.16 

7.62 

7.62 

3.03 

6.666 

235 

0.27 

1.4534 

8.33 

2 

1 

1 

3 

5.08 

2.54 

7.62 

1.3 

2.86 

saturates 

0.04 

0.19 

1.09 

2 

1 

1 

4 

5.08 

2.54 

10.16 

1.73 

3.806 

saturates 

0.04 

0.25 

1.43 

8 

6 

2 

1 

20.32 

15.24 

2.54 

4.04 

8.888 

50 

0.26 

1.3362 

7.66 

6 

4 

2 

1 

15.24 

10.16 

2.54 

2.88 

6.336 

135 

0.31 

1.5419 

8.83 

4 

2 

2 

1 

10.16 

5.08 

2.54 

1.73 

3.806 

270 

0.17 

1.2614 

7.23 

8 

6 

2 

2 

20.32 

15.24 

5.08 

8.07 

17.754 

25 

0.18 

0.921 

5.28 

6 

4 

2 

2 

15.24 

10.16 

5.08 

5.77 

12  694 

70 

0  23 

1.1296 

6.47 

4 

2 

2 

2 

10.16 

5.08 

5.08 

3.46 

7.612 

245 

0.24 

1.3558 

7.77 

4 

2 

2 

3 

10.16 

5.08 

7.62 

5.19 

11.418 

190 

0.23 

1.1789 

6.75 

|Steel  (density  =  7.85 

g/cc)  i 

| 

Outer 

Inner 

Outer 

Inner 

Max  wheel 

Yaw  rate 

Yaw  angle  Slew  rate 

radius 

radius 

width 

height 

radius 

radius 

height 

Whl  mass  Whl  mass 

speed 

at  5  sec 

at  10  sec 

1 0  sec  avg 

(inches) 

(inches) 

(inches) 

(inches) 

(cm) 

(cm) 

(cm) 

(kg) 

(lb)  . 

(rad/sec) 

(rad/sec) 

(rad) 

(deg/sec) 

8 

7 

1 

1 

20.32 

17.78 

2.54 

6.06 

13.332 

30 

0.22 

1.0845 

6.21 

6 

5 

1 

1 

15.24 

12.7 

2.54 

4.45 

9.79 

75 

0.26 

1.2856 

7.37 

4 

3 

1 

1 

10.16 

7.62 

2.54 

2.83 

6.226 

245 

0.27 

1.474 

8.45 

2 

1 

1 

1 

5.08 

2.54 

2.54 

1.21 

2  662 

saturates 

0.03 

0.19 

1.09 

8 

7 

t 

2 

20.32 

17.78 

5.08 

12.12 

26.664 

15 

D.14 

0.7029 

4.03 

6 

5 

1 

2 

15  24 

12.7 

5.08 

8.89 

19.558 

40 

0.17 

0.8773 

5.03 

4 

3 

1 

2 

10.16 

7.62 

5.08 

5.66 

12.452 

140 

0.23 

1.1394 

6.53 

2 

1 

1 

2 

5.08 

2.54 

5.08 

2.43 

5.346 

saturates 

0.05 

0.34 

1.95 

4 

3 

1 

3 

10.16 

7.62 

7.62 

8.49 

18.678 

95 

0.18 

0.9092 

5.21 

2 

1 

f 

3 

5.08 

2.54 

7.62 

3.64 

8.008 

saturates 

0.07 

0.55 

3.15 

2 

1 

1 

4 

5.08 

2.54 

10.16 

4.85 

10.67 

270 

0.08 

0.655 

3.75 

8 

6 

2 

1 

20.32 

15.24 

2.54 

11.32 

24.904 

18 

0.15 

0.7404 

4.24 

6 

4 

2 

1 

15.24 

10.16 

2.54 

8.08 

17.776 

50 

0.18 

0.9326 

5.34 

4 

2 

2 

1 

10.16 

5.08 

2.54 

4.85 

10.67 

200 

0.23 

1.2146 

6.96 

8 

6 

2 

2 

20.32 

15.24 

5.08 

22.63 

49.786 

10 

0.09 

0.4419 

2.53 

6 

4 

2 

2 

15.24 

10.16 

5.08 

16.17 

35.574 

25 

0.12 

0.5841 

3.35 

4 

2 

2 

2 

10.16 

5.08 

5.08 

9.7 

21.34 

105 

0.17 

0837 

4.80 

4 

2 

2 

3 

10.16 

5.08 

7.62 

14.55 

32.01 

70 

0.13 

0.6369 

3.65 

Notes:  1 .  Inilia!  conditions:  all  three  momentum  wheels  at  rest,  SimSal  at  rest,  all  euler  angles  zero 

2.  Positive  b,  side  -  molors,  momentum  wheels,  battery,  4  gyros 

3.  Negative  b,  side  -  Aulobox,  xmit/receiver,  counterweight 

4.  Max  allowable  wheel  speed  =  270  rad/sec  (2800  rpm) 

5.  Simulation  run  tor  1 0  seconds 

6.  Max  continuous  torque  curve  applied  to  motor  #2  tor  first  5  seconds, 

torque  reversed  to  motor  #2  for  seconds  5  through  10  (motors  #1  &  #3  motionless) 

7.  Effect  of  a  wheel  axle  is  ignored 

8.  36  volts  (simulated)  applied  to  motor  #2 
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Table  C.5  Aluminum  vs.  Steel  Hoops-Inertia  Held  Constant 


Momentum  Wheel  Analysis  (with  all  three  wheels  identical  size) 
tor  Wheel  #2 

Hoop  Shape-HOLDING  INERTIA  CONSTANT 


Outer 

Inner 

Hoop 

Hoop 

Outer 

Inner 

Hoop 

1(2,2) 

Max  wheel 

Yaw  rate 

Yaw  angle  Slew  rate 

radius 

radius 

width 

Ihickness 

radius 

radius 

Ihickness 

term 

Whl  mass  speed 

at  5  sec 

at  1 0  sec 

1 0  sec  avg 

(inches) 

(inches) 

(inches) 

(inches) 

(N-m-sec*) 

(kg)  (ratfsec) 

(rad/sec) 

(rad) 

(deg/sec) 

6 

5 

1 

1 

15.24 

12.7 

2.54 

0.031 

1.59  200 

0.35 

1.8348 

10.51 

4 

3 

1 

1 

10.16 

7.62 

2.54 

0.0D8 

1 .009  270 

0.14 

1.1325 

6.49 

4  3  1  2  10.16  7.62  5.08  0.016  2.02  265  0.23  1.4876  |  8.52 


Steel  (density  =  7.85  ^cc) 


Outer  Inner  Hoop  Hoop  Outer  Inner  Hoop  1(2,2)  Max  wheel  Yaw  rate  Yaw  angle  Slew  rale 

radius  radius  widlh  thickness  radius  radius  thickness  term  Whl  mass  speed  at  5  sec  at  10  sec  10  sec  avg 
(inches)  (inches)  (inches)  (inches)  (cm)  (cm)  (cm)  (N-m-sec*)  (kg)  (racflsec)  (rad/sec)  (rad)  (deg/sec) 

4.384488  3.384488  1  1  11.1366  8.5966  2.54  0.031  3.1397  200  0.29  1 .5009  8.60 

2.952008  1.952008  1  1  7.4981  4.9581  2.54  0.008  1.9819  270  0.12  1.0056  5.76 

2.952008  1.952008  1  2  7.4981  4.9581  5.08  0.016  3.9637  265  0.18  1.1548  6.62 


Notes:  1.  Initial  conditions:  all  three  momentum  wheels  at  rest,  SimSat  at  rest,  all  euler  angles  zero 

2.  Positive  b,  side  -  motors,  momentum  wheels,  battery,  4  gyros 

3.  Negative  b,  side  -  Autobox,  xmrt/receiver,  counterweight 

4.  Max  allowable  wheel  speed  =  270  rad/sec  (26D0  rpm) 

5.  Simulation  run  tor  10  seconds 

6.  Max  continuous  lorque  curve  applied  to  motor  #2  tor  tirst  5  seconds, 

torque  reversed  to  motor  #2  tor  seconds  5  through  1 0  (motors  #1  &  #3  motionless) 

7.  Ettecl  ot  a  wheel  axle  is  ignored 

8.  36  volts  (simulated)  applied  to  motor  #2 


Table  C.6  Aluminum  vs.  Steel  Hoops-Width  Variation  of  Steel  Hoop 


Momentum  Wheel  Analysis  (with  all  three  wheels  identical  size) 
tor  Wheel  #2 

Hoop  Shape-HOLDING  INERTIA  AND  OUTER  RADIUS  CONSTANT 


Outer 

Inner 

Hoop 

Hoop 

Outer 

Inner 

Hoop 

1(2,2) 

Max  wheel 

Yaw  rate 

Yaw  angle  Slew  rate 

radius 

radius 

width 

thickness 

radius 

radius 

thickness 

term 

Whl  mass 

speed 

at  5  sec 

at  1 0  sec 

1 0  sec  avg 

(inches) 

(inches) 

(inches) 

(inches) 

mSM 

mBM 

Jem) 

(N-m-sec*) 

(kg) 

(radfeec) 

(rad/sec) 

(rad) 

(deg/sec) 

6 

5 

1 

1 

15.24 

12.7 

2.54 

0.031 

1.59 

200 

0.35 

1.8348 

10.51 

4 

3 

1 

1 

10.16 

7.62 

2.54 

0.008 

1.009 

270 

0.14 

1.1325 

6.49 

4 

3 

1 

2 

10.16 

7.62 

5.08 

0.016 

2.02 

265 

0.23 

1 .4876 

8.52 

|Steel  (density  =  7.85  c 

^cc)  | 

| 

Outer 

Inner 

Hoop 

Hoop 

Outer 

Inner 

Hoop 

1(2,2) 

Max  wheel 

Yaw  rate 

Yaw  angle  Slew  rate 

radius 

radius 

width 

thickness 

radius 

radius 

thickness 

term 

Whl  mass 

speed 

at  5  sec 

at  10  sec 

1 0  sec  avg 

(inches) 

(inches) 

(inches) 

(inches) 

(cm) 

(cm) 

(N-m-sec*) 

(kg) 

(rack'sec) 

(rad/sec) 

(rad)  (deg/sec) 

Notes:  1 .  Initial  conditions:  all  three  momentum  wheels  at  rest,  SimSat  at  rest,  all  euler  angles  zero 

2.  Positive  b,  side  -  motors,  momentum  wheels,  battery,  4  gyros 

3.  Negative  bt  side  -  Autobox,  xmit/receiver,  counterweight 

4.  Max  allowable  wheel  speed  -  270  rad/sec  (2600  rpm) 

5.  Simulation  run  tor  10  seconds 

6  Max  continuous  lorque  curve  applied  to  motor  #2  for  tirst  5  seconds, 

torque  reversed  to  motor  #2  tor  seconds  5  through  1 0  (motors  #1  &  #3  motionless) 

7.  Effect  ot  a  wheel  axle  is  ignored 

8.  36  volts  (simulated)  applied  to  motor  #2 
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a  quick  “back-of-the-envelope”  wheel  structural  analysis  was  performed.  A  wheel  with 
excellent  inertia  properties  could  still  break  apart  when  spinning  at  high  speeds. 

Considering  only  hoop  stress,  the  bursting  velocity  of  a  momentum  wheel  is  approx¬ 
imated  by  [40:338]: 

V  =  n/10s 
where 

V  =  bursting  velocity  of  outside  circumference  of  rim  in  feet  per  second 

s  —  tensile  strength  of  the  rim  material  in  pounds  per  square  inch 

If  the  wheel  rim  is  conservatively  assumed  to  be  ASTM-A36  carbon  steel  (which  has 
one  of  the  lowest  steel  tensile  strengths),  s  =  36,000  psi  and  V  =  600  ft/sec  =  15,279  rpm. 
This  burst  velocity  is  well  above  the  maximum  SmartMotor  speed  rating  of  3400  rpm  (at 
48  V). 

Another  general  formula  which  takes  into  account  material  properties,  construction, 
rim  thickness,  and  joint  efficiencies  is  given  by  [40:341]: 

N  =  (C*A*M*E*K)/D 

where 

N  =  maximum  rated  operating  speed  in  revolutions  per  minute 
C  =  1.0  for  wheels  driven  by  a  constant  speed  electric  motor 
=  0.90  for  wheels  driven  by  variable  speed  motors 
A  =  0.90  for  4  arms  or  spokes 
=  1.00  for  6  arms  of  spokes 
=  1.08  for  8  arms  or  spokes 
=  1.50  for  disc  type 

M  =  1.00  for  cast  iron  of  20,000  psi  tensile  strength,  or  unknown 

=  1.12  for  cast  iron  of  25,000  psi  tensile  strength 

=  1.22  for  cast  iron  of  30,000  psi  tensile  strength 

=  1.32  for  cast  iron  of  35,000  psi  tensile  strength 
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=  2.20  for  nodular  iron  of  60,000  psi  tensile  strength 
=  2.45  for  cast  steel  of  60,000  psi  tensile  strength 
=  2.75  for  plate  or  forged  steel  of  60,000  psi  tensile  strength 
E  =  joint  efficiency 
=  1.0  for  solid  rim 
=  0.85  for  link  or  prison  joints 
=  0.75  for  split  rim-bolted  joint  at  arms 
=  0.70  for  split  rim-bolted  joint  between  arms 
K  =  1355  for  rim  thickness  equal  to  1%  of  outside  diameter 

=  1650  for  rim  thickness  equal  to  2%  of  outside  diameter 

=  1840  for  rim  thickness  equal  to  3%  of  outside  diameter 

=  1960  for  rim  thickness  equal  to  4%  of  outside  diameter 

=  2040  for  rim  thickness  equal  to  5%  of  outside  diameter 

=  2140  for  rim  thickness  equal  to  7%  of  outside  diameter 

=  2225  for  rim  thickness  equal  to  10%  of  outside  diameter 

=  2310  for  rim  thickness  equal  to  15%  of  outside  diameter 

=  2340  for  rim  thickness  equal  to  20%  of  outside  diameter 

D  =  outside  diameter  of  rim  in  feet 

Assuming  a  momentum  wheel  with  a  continuous  disk  for  “spokes”,  cast  steel  solid 
rim,  outside  diameter  of  9”,  and  a  rim  thickness  of  1”: 

N  =  (.90  *  1.5  *  2.45  *  1.0  *  2225)/0.75 

N  =  9812  rpm  (safely  exceeds  the  3400  rpm  capability  of  the  SmartMotor) 

After  completing  this  “rough”  structural  analysis,  detailed  design  of  the  wheels  con¬ 
tinued.  To  determine  the  wheel  dimensions  that  maximized  yaw  performance,  a  MATLAB 
constrained  optimization  approach  was  used: 
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Objective  (cost)  function  was:  Maximize  the  SIMS  AT  yaw  angle  at  t  =  10  seconds.  (By 
default,  this  also  maximizes  the  SIMSAT  10-second-average  slew  rate).  This  yaw  angle  was 
calculated  from  a  MATLAB  simulation  of  the  equations  of  motion  and  the  SmartMotor 
torque  curves  described  earlier. 

The  constraints  were: 

1)  Steel  hoop  with  a  width  >=  3/8"  (width  =  outer  radius  -  inner  radius) 

-This  constraint  was  used  to  prevent  the  optimization  routine  from  returning  an 
infinitely  small  hoop  width  (the  smaller  the  hoop  width,  the  better  the  yaw  performance). 
This  width  was  intuitively  chosen  so  there  was  enough  metal  available  for  strength  and 
“spoke”  attachment  purposes. 

2)  Solid  aluminum  disk  for  “spokes”,  aluminum  disk  is  >=  1/4"  thick. 

Note:  Outer  radius  of  the  aluminum  disk  is  equal  to  the  inner  radius  of  the  hoop.  Also, 
the  effect  of  a  wheel  axle  hole  was  ignored  for  the  optimization  routine. 

-A  solid  aluminum  disk  arrangement  was  chosen  because  it  would  be  easier  to  fabri¬ 
cate  and  be  stronger  than  spokes.  The  1/4"  disk  thickness  would  allow  enough  metal  for 
attachment  of  an  axle  but  would  be  thin  enough  to  still  approximate  a  theoretical  hoop. 
Although  a  theoretical  hoop  has  massless  spokes,  a  thin  aluminum  disk  would  be  a  good 
compromise.  Aircraft  grade  aluminum  has  excellent  strength  and  only  35%  the  density  of 
steel. 

3)  Thickness  (depth)  of  the  steel  hoop  >=  0.2" 

-This  constraint  was  imposed  to  prevent  the  optimization  routine  from  returning  a 
hoop  that  was  too  thin  to  fabricate. 

4)  Outer  radius  of  the  steel  hoop  <=  6" 

-This  constraint  was  imposed  to  prevent  the  optimization  routine  from  returning 
a  wheel  too  large  to  reasonably  integrate  onto  SIMSAT.  However,  this  constraint  was 
removed  for  certain  computer  runs. 

The  design  variables  were: 

-Outer  radius  of  the  steel  hoop 
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-Thickness  (depth)  of  the  steel  hoop 


After  mathematically  formulating  the  constrained  optimization  problem,  the  MAT- 
LAB  code  was  constructed.  The  MATLAB  SIMS  AT  motion  simulation  was  implemented 
within  a  MATLAB  optimization  driver  program.  The  first  computer  run  returned  a  wheel 
design  with  a  hoop  outer  radius  of  6"  (not  surprisingly,  on  the  edge  of  the  constraint 
boundary).  The  computer  program  was  then  run  with  a  4.5"  and  a  4"  constraint  on  the 
outer  hoop  radius.  The  program  was  also  run  for  the  36V  case  with  no  constraint  placed 
on  the  hoop  outer  radius.  Finally,  the  process  was  repeated  using  an  aluminum  disk  and 
an  aluminum  hoop  with  the  same  constraints.  The  results  of  the  optimization  for  the  steel 
hoop  and  aluminum  hoop  wheels  are  summarized  in  Table  C.7.  Results  in  this  table  are 
shown  for  motor  voltages  of  36V  and  24V. 


Table  C.7  Steel  and  Aluminum  Wheel  Optimization  at  36V  and  24V 


Optimized  Disk/Hoop  Shape  at  36V 

|Alumlnum  Hoop  1 


Outer 

Hoop 

Hoop 

Disk 

Outer 

Hoop 

Hoop 

Disk 

Max  wheel 

Vawrate 

Yaw  angle 

Slew  rate 

radius 

width 

thickness 

thickness 

radius 

widlh 

thickness 

thickness 

Whl  mass 

speed 

at  5  sec 

at  1 0  sec 

10  sec  avg 

(cm) 

(cm) 

(cm) 

(cm) 

(inches) 

(inches) 

(inches) 

(inches) 

■« 

(rad/sec) 

(rad/sec) 

(rad) 

(deg/sec) 

*15.8729 

0.9525 

0.508 

0.635 

6249 

0.375 

02 

0.25 

1.6695 

23B 

0.36 

1.8803  I 

10.77 

11.43 

0.9525 

3.3325 

0.635 

4.5 

0.375 

1.312008 

025 

1.9531 

258 

0.29 

1.6904 

9.69 

10.16 

0.9525 

5.0589 

0.635 

4 

0.375 

1.991693 

0.25 

22184 

262 

027 

1.5815  | 

9.06 

| Steel  Hoop 

I 

Outer 

Hoop 

Hoop 

Disk 

Outer 

Hoop 

Hoop 

Disk 

Max  wheel 

Yaw  rate 

Yaw  angle  Slew  rale 

radius 

width 

thicRness 

thickness 

radius 

width 

thickness 

thickness 

Whl  mass 

speed 

at  5  sec 

at  10  sec 

1 0  sec  avg 

(cm) 

(cm) 

(cm) 

(cm) 

(inches) 

(inches) 

(inches) 

(inches) 

mism 

(rad/sec) 

(rad/sec) 

(rad) 

*14.2625 

0.9525 

0.508 

0.635 

5.615 

0.375 

0.2 

025 

1.7943 

237 

0.35 

1.8334 

10.50 

11.43 

0.9525 

1 .1  893 

0.635 

4.5 

0.375 

0.468 

025 

1 .9538 

258 

029 

1 .6906 

9.69 

10.16 

0.9525 

1.8065 

0.635 

4 

0.375 

0.711 

025 

22203 

262 

027 

1.582 

9.06 

_  Optimized  Disk/Hoop  Shape  at  24V 

[Aluminum  Hoop  "1 


Outer 

Hoop 

Hoop 

Disk 

Outer 

Hoop 

Hoop 

Disk 

Max  wheel 

Yaw  rate 

Yaw  angle  Slew  rate 

radius 

width 

thickness 

thickness 

radius 

width 

thickness 

thickness 

Whl  mass 

speed 

at  5  sec 

at  1 0  sec 

10  sec  avg 

(cm) 

(cm) 

(cm) 

(cm) 

(inches) 

(inches) 

(inches) 

(inches) 

KM 

(rad/sec) 

(rad/sec) 

(rad) 

15.24 

0.9525 

0.6993 

0.635 

6 

0.375 

0275315 

025 

1 .6433 

160 

023 

12246 

[  7.02 

| Steel  Hoop 

Outer  Hoop 

1 

Hoop 

Disk 

Outer 

Hoop 

Hoop 

Disk 

Max  wheel 

Yaw  rate 

Yaw  angle 

Slew  rate 

radius 

width 

thickness 

thickness 

radius 

width 

thickness 

thickness 

Whl  mass 

speed 

at  5  sec 

at  10  sec 

10  sec  avg 

(cm) 

(cm) 

(cm) 

(cm) 

(inches) 

(inches) 

(inches) 

(inches) 

(kg) 

(rad/sec) 

(rad/sec) 

(rad) 

(deg/sec) 

11.43 

0.9525 

1.1889 

0.635 

4.5 

0.375 

0.468 

025 

1 .9534 

170 

0.19 

1.1139 

6.38 

10.16 

0.9525 

1 .7925 

0.635 

4 

0  375 

0.706 

025 

2  2076 

172 

0.18 

1.043B 

5.98 

Notes:  *  Unconstrained  outer  radius 

1 .  Initial  conditions:  all  three  momentum  wheels  at  rest,  SimSat  at  rest,  all  euler  angles  zero 

2.  Positive  bl  side -motors,  momentum  wheels,  battery.  4 gyros 

3.  Negative  bl  side  -  Autobox,  xmit/receiver,  counterweight 

4.  Max  allowable  wheel  speed  -  270  rad/sec  (2600  rpm) 

5.  Simulation  run  for  10  seconds 

6.  Max  continuous  torque  curve  applied  to  molor  #2  for  first  5  seconds, 

torque  reversed  to  motor  #2  for  seconds  5  through  10  (motors  #1  &  #3  motionless) 

7.  Effect  of  a  wheel  axle  is  ignored 

8  36  or  24  volts  (simulated)  applied  to  motor  #2 
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For  smaller  diameter  wheels  (8"  and  9"  diameter),  the  aluminum  and  steel  hoops 
have  the  same  performance,  but  the  aluminum  hoops  are  much  thicker.  If  no  constraint  is 
placed  on  the  outer  radius,  a  12.5"  diameter  aluminum  hoop  wheel  at  36V  yields  the  best 
performance. 


C.1.6  Final  Momentum  Wheel  Design  Alternatives.  With  yaw 
performance  numbers  in  hand,  six  momentum  wheel  design  alternatives  were  carried  for¬ 
ward  to  be  evaluated  at  the  overall  system  level.  Three  wheel  alternatives  for  a  24V 
bus  configuration  would  be  evaluated,  and  three  wheel  alternatives  for  a  36V  bus  would 
be  evaluated.  Even  though  an  infinite  number  of  wheel  alternatives  existed,  limiting  the 
number  of  alternatives  to  six  was  considered  to  be  tractable  in  a  system-level  evaluation 
matrix.  Table  C.8  shows  the  three  wheel  alternatives  for  a  36V  bus  and  the  three  wheel 
alternatives  for  a  24V  bus.  Figure  C.10  also  illustrates  these  alternatives. 


Table  C.8  Final  Wheel  Alternatives  for  36V  and  24V  Bus 

Momentum  Wheel  Alternatives  for  36  Volt  Bus 


|Alumlnum  Hoop  ~\ 


Outer 

radius 

(cm) 

Hoop 

width 

(cm) 

Hoop 

thickness 

(cm) 

Disk 

thickness 

(cm) 

Outer 

radius 

(inches) 

Hoop 

width 

(inches) 

Hoop 

thickness 

(inches) 

Disk 

thickness  Whl  mass 
(inches)  (kg) 

Max  wheel 
speed 
(rad/sec) 

Yaw  rate 
at  5  sec 
(rad/sec) 

Yaw  angle 
at  1 0  sec 
(rad) 

f  Slew  rate 
10  sec  avg 
(deg/sec) 

15.8729 

0.9525 

0.508 

0.635 

6.249 

0.375 

0.2 

0.25 

1.6695 

238 

0.36 

1.8803 

1  10.77 

{Steel  Hoop 

1 

Outer 

Hoop 

Hoop 

Disk 

Outer 

Hoop 

Hoop 

Disk 

Max  wheel 

Yaw  rate 

Yaw  angle  Slew  rate 

radius 

width 

thickness 

thickness 

radius 

width 

thickness 

thickness  Whi  mass 

speed 

at  5  sec 

at  10  sec 

10  sec  avg 

(cm) 

(cm) 

(cm) 

(cm) 

(inches) 

(inches) 

(inches) 

(inches) 

(kg) 

(rad/sec) 

(rad/sec) 

(rad) 

(deg/sec) 

11.43 

0.9525 

1.1893 

0.635 

4.5 

0.375 

0,468 

0.25 

1.9538 

258 

0.29 

1 .6906 

9.69 

10.16 

0,9525 

1.8065 

0.635 

4 

0.375 

0.711 

0.25 

2.2203 

262 

0.27 

1.582 

9.06 

Momentum  Wheel  Alternatives  for  24  Volt  Bus 


{Aluminum  Hoop 


Outer 

Hoop 

Hoop 

Disk 

Outer 

Hoop 

Hoop 

Disk 

Max  wheel 

Yaw  rate 

Yaw  angle  Slew  rate 

radius 

width 

thickness 

thickness 

radius 

width 

thickness 

thickness  Whl  mass 

speed 

at  5  sec 

at  10  sec 

10  sec  avg 

(cm) 

(cm) 

(cm) 

(cm) 

(inches) 

(inches) 

(inches) 

(inches) 

(kg) 

(rad/sec) 

(rad/sec) 

(rad) 

(deg/sec) 

15.24 

0.9525 

0.6993 

0.635 

6 

0.375 

0.275315 

0.25 

1.6433 

160 

0.23 

1.2246 

nr 

{Steel  Hoop  ] 


Outer 

Hoop 

Hoop 

Disk 

Outer 

Hoop 

Hoop 

Disk 

Max  wheel 

Yaw  rate  Yaw  angle  Slew  rate 

radius 

width 

thickness 

thickness 

radius 

width 

thickness 

thickness  Whl  mass 

speed 

at  5  sec 

at  10  sec 

1 0  sec  avg 

(cm) 

(cm) 

(cm) 

(cm) 

(inches) 

(inches) 

(inches) 

(inches) 

(kg) 

(rad/sec) 

(rad/sec) 

(rad) 

(deg/sec) 

11.43 

0.9525 

1.1889 

0.635 

4.5 

0,468 

0.25 

1.9534 

170 

0.19 

1.1139 

10.16 

0.9525 

1.7925 

0.635 

4 

0.375 

0.706 

0.25 

2.2076 

172 

0.18 

1.0438 

5.98 
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Hoop 


12.5"  Outer  Diameter  9"  Outer  Diameter  8"  Outer  Diameter 


Notes: 

-All  hoop  widths  are  3/8"  (width  is  measured  in  plane  of  page) 

-All  inner  aluminum  disks  are  1/4"  thick,  disks  are  centered  with 
reference  to  hoop  thickness 

-See  Table  for  hoop  thicknesses  (varies  for  24V  or  36V  bus  voltage) 
-Thickness  is  measured  into/out  of  page 


Figure  C.10  Sizes  of  Final  Wheel  Alternatives 

Reasons  for  choosing  the  three  different  outer  diameters  were  as  follows: 

1)  12.5"  outer  diameter  (for  36V  case,  12"  outer  diameter  for  the  24V  case)  aluminum 
hoop  wheel  with  inner  aluminum  disk 

-This  was  the  best  yaw  performance  alternative  from  a  wheel  subsystem  perspective. 
However,  the  placement  of  three  large-sized  momentum  wheels  on  SIMS  AT  could  create 
system-level  integration  challenges. 

2)  9"  outer  diameter  steel  hoop  wheel  with  inner  aluminum  disk 

-A  medium  yaw  performance  wheel  that  had  a  medium  size.  A  steel  hoop  was  chosen 
because  it  offers  the  same  performance  and  weight  as  a  9"  diameter  aluminum  hoop,  but 
a  steel  hoop  is  thinner.  A  thinner  hoop  allows  a  tighter  packaging  arrangement  for  three 
wheels. 

3)  8"  outer  diameter  steel  hoop  wheel  with  inner  aluminum  disk- 

-A  low  yaw  performance  wheel  that  had  a  small  size.  Its  size  may  allow  easier 
integration  onboard  SIMS  AT 

These  wheel  alternatives  effectively  captured  performance  (low,  medium,  and  high) 
vs.  size  (large,  medium,  and  small).  System-level  evaluation  of  the  momentum  wheel 
alternatives  could  now  begin. 


C-23 


Appendix  D.  Gyro  Range  and  Accuracy 

Analysis 

D.l  Overview 

This  appendix  presents  the  methodology  and  data  used  to  specify  the  Humphrey 
CF75  rate  gyro  range  required  for  the  SIMS  AT  application.  Determination  of  gyro  accu¬ 
racy  is  included  as  part  of  this  analysis,  as  well.  The  first  part  of  the  discussion  explains 
how  estimates  for  maximum  roll,  pitch,  and  yaw  rates  were  determined.  The  second  section 
shows  our  analysis.  The  last  section  covers  what  choices  were  made. 


D.2  Rate  Determination 

The  following  Mathcad  7  document  was  used  in  determining  the  estimated  slew  rates 
for  SIMS  AT  with  thrusters.  At  this  point  in  the  design  process,  it  was  desirable  to  select 
the  gyro  ranges  to  account  for  the  possibility  of  thrusters  being  added  to  the  baseline 
design. 
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Thruster  slew  rate  calculations : 


For  our  system,  we  are  going  to  use  two  tri-axial  thruster  systems  on 
either  wing  of  Simsat.  Here  is  what  we  know  about  the  thrusters  and  the 
two  air  tanks  we  have  chosen: 


F  :=  25.35  N 


At 


min 


.005  s 


m4x  :=  .14  kg 

mclO:=12kS 


Using  SMAD  and  Chobotov,  the  best  equation  for  determining  slew  rate  based 
on  the  thrust  of  a  system  is: 

(F-L-At) 

0dot(F,L,At,I)  — j— 

F  ~  Thrust  (in  N) 

L  ~  Moment  arm  for  thruster  (in  m) 

Dt  ~  Impulse  duration  (in  sec) 

I  ~  Moment  of  Inertia  (in  kg*mA2) 

L;=  1  m  for  pitch  and  yaw  axes.  This  is  an  estimate 

pun  intended) . 

L roil  := -05  m  due  to  the  Tri-axial  thruster,  we  will  pay  a 
roll  qdot. 


at  the  moment  (no 
penalty  for  the 


For  the  moments  of  inertia,  our  latest  estimates  are  (from  using  our 
inertia4 .m)  : 

Iroii;=4.5kgm2 

1  pitch  ;=  17-2  kg  m2 
Iyaw:=15.8kgtn2 
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To  find  Dt,  we  first  need  to  solve  for  the  mass  flow  rate,  mdot .  We  used 
a  generic  Isp  value  from  SMAD  of  50s  for  cold  gas  jet  thrusters.  SMAD  had 
a  vacuum  Isp  range  of  50s  to  75s.  We  are  attempting  to  be  conservative 
with  50s  since  we  are  not  operating  in  a  vacuum. 


Isp  :=  50  s  mdot  ;= 


Isp-g 


mdot  -  0.052 


>'g 


A,4xr 


m4x 

mdot 


1  clO 


clO 


mdot 


At4x=  2.708-s  Atcl0  =  2.321-s 


These  values  represent  a  single  burn 
with  durations  of  2.71  seconds  and 
2 . 321  seconds .  A  smarter  way  would  be 
using  x  amount  of  shorter  pulses 
instead  of  one  big  pulse.  However, 
for  our  initial  estimates  for  max 
angular  rate,  it  will  work. 


So,  for  a  max  angular  velocity  due  to  a  single  burn  (pure  spinner),  we  cret: 


Roll  Ddo.(F,  LroU,  A,  4x.Iro„)=  43.702-Si 
edo.(F,Lroii,4«ci0.lroll)  =  37.459^i 

Pitch  edot  (f  ,  L,  At  4x ,  I  pitchj  =  228.672 

edo.(F,L,  4.  do.1  pitch)  =196-005^ 


We  are  paying  a  severe  penalty 
for  having  such  a  small  moment 
arm  for  the  roll  axis.  We  may 
need  to  consider  using  a  separate 
thruster  for  the  roll  axis 
mounted  further  from  the  roll 
axis . 


6dot  (F,  L,  At  4x ,  I  yaw)  =  248.934 
0dot(F,L.Atclo,Iyaw)  =  213.372 
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As  you  can  see  from  this  Mathcad  document  and  the  Excel  spreadsheet,  we 
will  need  to  trade  the  value  of  a  higher  slew  rate  versus  the  value  of 
position  accuracy  using  the  VSD.  Nudge  proposed  the  idea  of  using  the 
Horizon  gyros  for  the  educational  experiments  (pure  spin,  dual  spin)  and 
using  the  Humphrey  gyro  for  the  three  axis  experiments.  This  would  allow 
you  to  sense  the  high  rates  (up  to  720  deg/sec)  for  the  spin  experiments 
while  not  being  concerned  about  the  position  accuracy. 


Here  is  a  quick  estimate  for  your  maneuver  in  a  certain  amount  of  time. 
Let's  begin  with  a  disclaimer  stating  this  method  assumes  a  fixed  amount 
of  thrust  for  any  duration  (not  gonna  happen) .  I  supposed  we  had  a  LEO 
satellite  at  given  altitude  (below  1000km)  .  The  maximum  angle  slew  from 
horizon  to  horizon  with  respect  to  the  earth  is: 


r  :=  6378  km 


H  :=  100  km,  120  km..  1000  km 


0max(H)  :=  2-asin 


0max(  100  km)  =  159.839 *deg 


At  :=  .94  s 

(2-8dot(F,L,4t,Iyaw)-it)  =  162.454  *deg 
edot  (F,  L,  At ,  1  yaw)  =  86.4 1 1 
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So  according  to  our  numbers,  if  we  lived  in  a  perfect  world,  we  could  slew 
our  satellite  162  degrees  in  1.88  seconds.  This  would  give  us  a  rate  of 
86.411  deg/s.  We  can  scale  this  back  and  say  we  would  need  an  80  deg/s 
slew  rate  sensing  capability  for  thruster  assist  maneuvers.  Using  the 
Excel  spreadsheet,  this  gives  us  the  following  accuracies: 


5HalfRange  :=  0.8 - 

s 


SHalftoFuIlRange  :=  3.2  — 
s 

I  am  assuming  the  yaw  axis  is  the  only  axis  of  interest.  Otherwise,  we 
would  want  to  use  momentum  wheels  for  a  three-axis  situation. 
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D.3  Range  and  Accuracy  Analysis 


To  select  the  best  gyro  for  the  SIMS  AT  design,  a  comparison  of  rate  ranges  was 
performed  using  utility  analysis.  The  two  measurables  chosen  were  sensing  range  and  ac¬ 
curacy  to  discriminate  between  alternatives.  For  each  axis,  utility  scores  were  calculated 
for  both  range  and  accuracy  for  the  different  choices.  Then,  using  the  weighting  factors 
within  the  system  level  VSD,  a  final  utility  score  was  calculated.  For  Tables  D.l  and  D.2, 
it  is  necessary  to  describe  each  column  and  its  formula  (if  applicable). 

Range  -  Sensing  Range  of  the  Gyro  in  a  given  axis  (deg/s) 

Accuracy  -  Sensing  Accuracy  of  the  gyro  in  a  given  axis  (deg/s) 

Range  Utility  -  Utility  based  on  minimum  range  requirements  of  a  given  axis  and  the 
maximum  capability  of  200  deg/s  (unitless) 

Formula:  0.006429  *  (Range)  —  0.2858 

Accuracy  Utility  -  Utility  based  on  0.0  as  a  maximum  accuracy  and  4.4  as  a  minimum 
accuracy 

Formula:  —0.204545  *  ( Accuracy )  +  1 
RPM  -  Revolutions  Per  Minute  (in  RPMs) 

Final  Utility  -  Utility  composed  of  the  range  and  the  accuracy  with  respect  to  the  VSD 
measurable  weighting 

Formula:  0.5  *  0.4  *  0.4  *  (0.4  *  Range )  *  (0.2  *  Accuracy) 

Utility  -  Utility  composed  of  the  range  and  the  accuracy  without  the  measurable  weighting 
Formula:  (0.4  *  Range)  *  (0.2  *  Accuracy) 
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Roll  Axis  (Maximum  Rate  without  thrusters  is  57.3  deg) 

Range:  60-200  deg/s  is  acceptable.  Anything  below  60  deg/s  will  not  meet  the  max  rate 
and  will  score  a  zero. 

Accuracy:  1.2  to  4.4  deg/s  using  the  range  above. 

Prom  60  deg/s  to  110  deg/s  range,  the  gyro  is  operating  in  the  half- to- full  range  mode. 
However,  from  120  deg/s  to  200  deg/s,  the  gyros  are  always  running  in  the  half  range 
mode.  Therefore,  the  accuracy  of  the  gyro  improves  from  4.4  deg/s  to  1.2  deg/s. 


Table  D.l  Roll  Range  Utility  ■ 


Range 

Accuracy 

Range  Utility 

Accuracy  Utility 

RPM 

Final  Utility 

Utility 

0.000 

0.000 

30 

1.2 

0.000 

0.000 

1.6 

llEfl 

awFMi 

■ESI 

2.4 

0.100 

10.00 

0.0003 

70 

2.8 

0.164 

■nr sa 

BfRfjWSl 

3.2 

0.229 

0.345 

3.6 

0.293 

0.264 

mil 

0.0005 

0.0062 

100 

4.0 

0.357 

0.182 

110 

4.4 

0.421 

0.100 

U&U 

120 

1.2 

0.486 

0.755 

wmma 

0.0293 

130 

1.3 

0.550 

0.734 

tana 

0.0323 

140 

1.4 

0.614 

0.714 

23.33 

0.0028 

150 

1.5 

0.679 

0.693 

25.00 

160 

1.6 

0.743 

0.673 

26.66 

IKIliSI 

170 

1.7 

0.807 

0.652 

28.33 

0.0034 

180 

1.8 

0.871 

fffWi!PMliWl 

■EHSH 

0.0440 

190 

1.9 

0.936 

0.0458 

200 

2.0 

1.000 

0.591 

33.33 

0.0038 

0.0473 
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Pitch/Yaw  Axis  (Maximum  Rate  with  thrusters  is  around  80  deg/s) 

Range:  80-200  deg/s  is  acceptable.  Anything  below  80  deg/s  will  not  meet  the  max  rate 
and  score  a  zero.  Anything  above  160  deg/s  will  score  a  1. 

Accuracy:  1.6-6.0  deg/s  using  the  ranges  above. 

Prom  80  deg/s  to  150  deg/s  range,  the  gyro  is  operating  in  the  half-to-full  range  mode. 
However,  from  160  deg/s  to  200  deg/s,  the  gyros  are  always  running  in  the  half  range 
mode.  Therefore,  the  accuracy  of  the  gyro  improves  from  6.0  deg/s  to  1.6  deg/s. 


Table  D.2  Pitch/Yaw  Range  Utility 


Range 

Accuracy 

Range  Utility 

Accuracy  Utility 

RPM 

Final  Utility 

Utility 

20 

0.8 

0.000 

0.000 

KlU 

0.0000 

1.2 

0.000 

0.000 

■iflllM 

0.0000 

1.6 

0.000 

0.000 

2.0 

0.000 

0.000 

liTilitiTil 

2.4 

0.000 

0.000 

Eliljl 

70 

2.8 

0.000 

■IliVJ 

lilMim 

80 

0.100 

90 

3.6 

0.213 

0.0006 

100 

4.0 

0.325 

BI&E1 

0.0008 

HIlHlEB 

110 

4.4 

0.438 

0.340 

ETima 

ms 

4.8 

0.550 

UTMg 

5.2 

0.663 

140 

5.6 

0.775 

0.160 

150 

0.888 

0.100 

160 

1.6 

1.000 

0.760 

EH 

1.7 

1.000 

0.745 

0.0048 

0.0596 

180 

1.8 

1.000 

0.730 

30.00 

0.0047 

0.0584 

190 

1.9 

1.000 

0.715 

31.66 

0.0046 

0.0572 

200 

2.0 

1.000 

0.700 

33.33 

0.0045 

0.0560 
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D.4  Design  Decisions 

Using  the  utility  figures,  the  best  choice  for  each  axis  was  a  200  deg/s  roll  rate  range 
and  a  160  deg/s  pitch/ yaw  rate  range.  However,  this  utility  analysis  was  strongly  based 
upon  the  range  being  twice  as  important  as  accuracy  within  the  VSD.  However,  after 
reviewing  the  figures  with  the  chief  decision  maker,  the  decision  was  made  to  place  greater 
importance  on  the  accuracy  of  the  system.  Therefore,  the  chief  decision  making  authority 
requested  a  roll  rate  range  of  120  deg/s  and  pitch/yaw  rate  ranges  of  ±  40  deg/s. 
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Appendix  E.  Gyro  Calibration  Curves 

E.l  Overview 

This  section  contains  all  the  manufacturer’s  information  on  the  Humphrey  CF75 
Gyro.  Regression  analysis  using  Excel  was  performed  to  create  a  best-fit  curve.  The 
formulas  developed  in  this  section  were  used  to  convert  incoming  gyro  signals  to  rate  and 
acceleration  inputs  within  the  Simulink  code. 
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E.2  Pitch  Axis  Regression 

Best  Fit  Curve  Formula:  PitchRate  =  16.01418821  *  OutputVoltage  —  40.13635991 


Table  E.l  Pitch  Axis  Gyro  Regression  Analysis 


Delta 

EEHHI 

0.008 

-40 

-40.0082464 

0.008246404 

0.508 

-32.0011523 

BHEEB9HHI 

-31.96912392 

BTmKWBWrtiviiM 

-23.96202982 

-0.037970182 

-23.93000144 

-0.069998559 

-16.05102084 

0.051020842 

1.511 

-16 

-15.93892152 

-0.061078475 

2.006 

-8 

-8.011898361 

0.011898361 

2.009 

-8 

-7.963855796 

-0.036144204 

2.505 

0 

-0.020818444 

0.020818444 

2.507 

0 

0.011209932 

-0.011209932 

3.001 

8 

7.922218908 

0.077781092 

3.005 

8 

7.986275661 

0.013724339 

3.506 

16 

16.00938395 

-0.009383954 

3.509 

16 

16.05742652 

-0.057426519 

4.009 

24 

24.06452062 

-0.064520624 

4.012 

24 

24.11256319 

-0.112563189 

4.506 

32 

32.02357216 

-0.023572164 

4.509 

32 

32.07161473 

-0.071614729 

5.014 

40 

40.15877977 

-0.158779775 

5.016 

40 

40.19080815 

-0.190808151 
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E.3  Roll  Axis  Regression 

Best  Fit  Curve  Formula:  Roll  Rate  =  47.67069299  *  OutputVoltage  —  119.2577727 


Table  E.2  Roll  Axis  Gyro  Regression  Analysis 


Output  Voltage 

Truth 

Roll  Rate 

Delta 

-0.015 

-120 

-119.9728331 

-0.027166905 

-120 

-119.829821 

-0.170178984 

0.490 

-96 

-95.89913313 

-0.100866865 

0.492 

-96 

-95.80379175 

-0.196208251 

0.990 

-72 

-72.06378664 

0.06378664 

0.992 

-72 

-71.96844525 

-0.031554746 

1.495 

-48 

-47.99008668 

-0.00991332 

1.498 

-48 

-47.8470746 

-0.152925399 

1.996 

-24 

-24.10706949 

0.107069492 

1.998 

-24 

-24.01172811 

0.011728106 

-0.081040225 

0.081040225 

— ' SiTfrll 

0.014301161 

-0.014301161 

3.002 

24 

23.84964766 

0.150352344 

3.005 

23.99265973 

0.007340265 

48 

48.018689 

-0.018689002 

3.512 

48 

48.16170108 

-0.161701081 

4.011 

72 

71.94937688 

0.050623117 

4.015 

72 

72.14005965 

-0.140059655 

4.511 

96 

95.78472338 

0.215276622 

96 

95.88006476 

0.119935236 

5.010 

120 

119.5723992 

0.42760082 

5.012 

120 

119.6677406 

0.332259434 
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Roll  Rate  vs.  Output  Voltage 


—♦—1st  Run 
2nd  Run 
. .  Regression 


Figure  E.2  Roll  Rate  vs.  Output  Voltage 


E.4  Yaw  Axis  Regression 

Best  Fit  Curve  Formula:  YawRate  =  16.07699608  *  OutputV oltage  —  40.28734448 


Table  E.3  Yaw  Axis  Gyro  Regression  Analysis 


Output  Voltage 

Truth 

Yaw  Rate 

Delta 

0.017 

-40 

-40.01403555 

0.014035547 

0.019 

-40 

-39.98188155 

-0.018118446 

0.509 

-32 

-32.10415348 

0.104153475 

0.512 

-32 

-32.05592249 

0.055922487 

1.010 

-24 

-24.04957844 

0.049578439 

1.012 

-24 

-24.01742445 

0.017424447 

1.508 

-16 

-16.04323439 

0.043234391 

1.509 

-16 

-16.0271574 

0.027157395 

2.008 

-8 

-8.004736351 

0.004736351 

2.013 

-8 

-7.924351371 

-0.075648629 

2.507 

0 

0.017684693 

-0.017684693 

i~  2.509  1 

0 

0.049838685 

-0.049838685 

3.001 

8 

7.959720756 

0.040279244 

3.002 

8 

7.975797752 

0.024202248 

3.500 

16 

15.9821418 

0.0178582 

3.502 

16 

16.01429579 

-0.014295792 

4.000 

24 

24.02063984 

-0.02063984 

4.003 

24 

24.06887083 

-0.068870828 

4.508 

32 

32.18775385 

-0.187753849 

4.511 

32 

32.23598484 

-0.235984837 

5.012 

40 

40.29055987 

-0.290559873 

5.014 

40 

40.32271387 

-0.322713865 
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E.5  Fore/ Aft  Acceleration  Regression 

Best  Fit  Curve  Formula:  Acceleration  =  1.985948707  *  OutputVoltage  —  4.967038257 


Table  E.4  Fore/Aft  Acceleration  Regression  Analysis 


Output  Voltage 

Truth 

Measured  Gs 

Delta 

0.005 

-5 

-4.957108513 

-0.042891487 

-5 

-4.957108513 

-0.042891487 

-4 

-4.063431595 

0.063431595 

-4 

-4.011796929 

0.011796929 

0.956 

-3 

-3.068471293 

0.068471293 

1.012 

-3 

-2.957258166 

-0.042741834 

1.457 

-2 

-2.073510991 

0.073510991 

1.517 

-2 

-1.954354068 

-0.045645932 

1.958 

-1 

-1.078550689 

0.078550689 

2.048 

-1 

-0.899815305 

-0.100184695 

2.464 

0 

-0.073660643 

0.073660643 

0 

-0.014082182 

0.014082182 

2.985 

1 

0.961018633 

0.038981367 

3.055 

1 

1.100035043 

-0.100035043 

3.500 

2 

1.983782218 

0.016217783 

3.551 

2 

2.085065602 

-0.085065602 

3.996 

2.968812776 

0.031187224 

4.056 

3 

3.087969699 

-0.087969699 

4.512 

4 

3.993562309 

0.006437691 

4.542 

4 

4.05314077 

-0.05314077 

4.987 

5 

4.936887945 

0.063112055 

4.988 

5 

4.938873894 

0.061126106 
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E.6  Lateral  Acceleration  Regression 

Best  Fit  Curve  Formula:  Acceleration  =  2.004813213  *  OutputV oltage  —  5.001917838 


Table  E.5  Lateral  Acceleration  Regression  Analysis 


Output  Voltage 

Truth 

Measured  Gs 

Delta 

0.005 

-5 

-4.991893772 

-0.008106228 

0.005 

-5 

-4.991893772 

-0.008106228 

-4 

-4.037602683 

0.037602683 

-4 

-3.977458286 

-0.022541714 

0.981 

-3 

-3.035196076 

0.035196076 

-3 

-2.973046866 

-0.026953134 

1.457 

-2 

-2.080904987 

0.080904987 

1.537 

-2 

-1.92051993 

-0.07948007 

1.978 

-1 

-1.036397303 

0.036397303 

2.033 

-1 

-0.926132576 

-0.073867424 

2.464 

0 

-0.062058081 

0.062058081 

2.489 

0 

-0.011937751 

0.011937751 

2.975 

1 

0.962401471 

0.037598529 

3.035 

1 

1.082690263 

-0.082690263 

3.470 

2 

1.954784011 

0.045215989 

3.521 

2 

2.057029485 

-0.057029485 

2.969219497 

0.030780503 

3 

3.039387959 

-0.039387959 

4.477 

4 

3.973630917 

0.026369083 

4,507 

4 

4.033775313 

-0.033775313 

4.982 

5 

4.986061589 

0.013938411 

4.982 

5 

4.986061589 

0.013938411 
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Acceleration  (in  G) 


Lateral  Acceleration  vs.  Output  Voltage 


DC  Voltage  (In  V) 


Figure  E.5  Lateral  Acceleration  vs.  Output  Voltage 


E- 


E.7  Vertical  Acceleration  Regression 

Best  Fit  Curve  Formula:  Acceleration  =  1.990529233  *  OutputVoltage  —  4.975418296 


Table  E.6  Vertical  Acceleration  Regression  Analysis 


Output  Voltage 

Truth 

Measured  Gs 

Delta 

0.005 

-5 

-4.96546565 

-0.03453435 

0.005 

-5 

-4.96546565 

-0.03453435 

mtmmm 

-4 

-4.008021089 

0.008021089 

-4 

-3.938352566 

-0.061647434 

I 

-3 

-3.092377642 

0.092377642 

■ 

-3.002803826 

0.002803826 

1.452 

-2 

-2.08516985 

0.08516985 

-2 

-1.975690742 

-0.024309258 

1.948 

-1 

-1.09786735 

0.09786735 

-1 

-0.908767073 

-0.091232927 

2.459 

0 

-0.080706912 

0.080706912 

2.504 

0 

0.008866903 

-0.008866903 

2.985 

1 

0.966311465 

0.033688535 

3.050 

1 

1.095695865 

-0.095695865 

3.490 

2 

1.971528727 

0.028471273 

3.546 

2 

2.082998364 

-0.082998364 

3.986 

3 

2.958831227 

0.041168773 

4.041 

3 

3.068310335 

-0.068310335 

4.502 

4 

3.985944311 

0.014055689 

4.527 

4 

4.035707542 

-0.035707542 

4.998 

5 

4.973246811 

0.026753189 

4.998 

5 

4.973246811 

0.026753189 
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Acceleration  (In  G) 


Vertical  Acceleration  vs.  Output  Voltage 
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.ii.inn.ui  Regression 


Figure  E.6  Vertical  Acceleration  vs.  Output  Voltage 
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Appendix  F.  Detailed  Design  Raw 
Values  &  Scoring 


F.  1  Overview 

The  first  iteration  of  Detailed  Design  evaluated  60  system  alternatives.  This  appendix 
presents  the  raw  data  for  each  objective  measurable  of  this  design  iteration.  In  addition, 
the  complete  ranking  of  system  alternatives  is  shown,  based  on  the  raw  values,  utility 
conversions,  and  weighting  factors. 


F.2  Objective  Measurables  Raw  Data 

The  raw  data  values  used  in  the  evaluation  of  each  objective  measurable  are  shown 
in  Tables  F.l  and  F.2. 


F.3  System  Scoring 

The  60  system  alternatives  considered  in  the  first  iteration  of  Detailed  Design  are 
sorted  by  system  score  in  Table  F.3. 


Table  F.l  Detailed  Design  Raw  Values 


SYSTEM  ALTERNATE 

MOTOR  WHEEL  GYRO 
TYPE  SIZE  OPTION 

ES 

BATTERY 

Slew  Rale 

Sensing 

Rate  Sensing 
Accuracy 

Comparative 

Volume  (cubic  in] 

CDH  Compatibility/ 

Interface 

OPTION 

Motore.  Satlenes::  TOTAL! 

ISB3II 

■SBH1 

Wheel  Boxes  Batteries  TOTAL 

MBhI 

Dumb 

12.5' 

Humphrey 

3-bat1-18 

lilll 

111111 

5513 

20 

High 

4& 

:4&i  ; 

913 

High 

10.77 

Dumb 

12.5’ 

Humphrey 

3-batM  2 

ilili 

llil 

5485 

20 

High 

48g  .J 

747 

High 

10.77 

Dumb 

12.5’ 

Humphrey 

3-batt-IO 

lliil 

5456 

20 

High 

•  • 

757 

High 

10.77 

Dumb 

12.5’ 

Humphrey 

2-batt-18 

5451 

20 

High 

I: . Mm . 

280  j 

772 

High 

7.00 

Dumb 

12.5’ 

Humphrey 

2-batt-12 

ffill 

iili 

5419 

20 

High 

5  492 

i  11  • 

662 

High 

7.00 

Dumb 

12.5’ 

Horizon 

3-bait- 18 

mm 

♦66 

5513 

720 

Low 

492. 

.421 

913 

High 

10.77 

Dumb 

12.5’ 

Horizon 

3-bat1-12 

Mil 

11111 

5465 

720 

Low 

492 

255 

747 

High 

10.77 

Dumb 

12.5’ 

Horizon 

3-batt-10 

iili 

*31 

5456 

720 

Low 

492.  . 

i|i|:  || 

757 

High 

10.77 

Dumb 

12.5’ 

Horizon 

2-batt-1 8 

iiili 

HI® 

5451 

720 

Low 

482  I 

.  :28D  :j 

772 

High 

7,00 

Dumb 

12.5’ 

Horizon 

2-bati-12 

iili 

Iiili 

5419 

720 

Low 

!  455 

t?Q 

662 

High 

7.00 

Dumb 

9’ 

Humphrey 

3-batt-18 

iili 

;•  m  • 

5513 

20 

High 

32 a 

421 

741 

High 

9.69 

Dumb 

9* 

Humphrey 

3-batt-12 

iili 

140  ii 

5465 

20 

High 

320  | 

255 

575 

High 

9.69 

Dumb 

9’ 

Humphrey 

3-bat1-10 

5325 

5456 

20 

High 

i! 

:;g.285 

585 

High 

9.69 

Dumb 

9’ 

Humphrey 

2-bat1-18 

5325 

5451 

20 

High 

32&  | 

260 

600 

High  , 

6.38 

Dumb 

9’ 

Humphrey 

2-batt-12 

iili 

■iiili 

5419 

20 

High 

320 

..170 

490 

High 

6.38 

Dumb 

9" 

Horizon 

3-batt-18 

5325 

iso  ■; 

5513 

720 

Low 

32fr 

•:;:;;-421 

741 

High 

9.69 

Dumb 

9' 

Horizon 

3-ba1t-i2 

'  5325- .  | 

•••  m 

5465 

720 

Low 

iiiiil 

mmm 

575 

High 

9.69 

Dumb 

9" 

Horizon 

3-bat1-10 

5325 

ill® 

5456 

720 

Low 

I:  320- 

••265 

585 

High 

9.69 

Dumb 

9- 

Horizon 

2-batt-18 

•5325 

lliii 

5451 

720 

Low 

320 

280 

600 

High 

6.38 

Dumb 

9* 

Horizon 

2-bati-12 

.5325 

ill! 

5419 

720 

Low 

§1  320 

17Q 

490 

High 

6.38 

Dumb 

8’ 

Humphrey 

3-batt-18 

iili; 

.  m 

5513 

20 

High 

V  '  300  ••§ 

421 

721 

High 

9.06 

Dumb 

8* 

Humphrey 

3-ba1t-12 

5325 

lliii  i 

5465 

20 

High 

300 

•  255 

555 

High 

9.06 

Dumb 

8' 

Humphrey 

3-ba11-10 

5325 

5456 

20 

High 

300  g 

565 

High 

9.06 

Dumb 

8’ 

Humphrey 

2-bat1-18 

liili 

i28 

5451 

20 

High 

300  | 

•  260 

580 

High 

5.98 

Dumb 

8" 

Humphrey 

2-batt-12 

iili 

■  m  ;■ 

5419 

20 

High 

3po 

mm 

470 

High 

5.98 

Dumb 

8’ 

Horizon 

3-batt-18 

iiili 

186;. 

5513 

720 

Low 

I:  m 

|| :  :•  421  ; 

721 

High 

9.06 

Dumb 

8" 

Horizon 

3-batt-12 

IB 

mm 

5465 

720 

Low 

300  | 

255 

555 

High 

9.06 

Dumb 

8’ 

Horizon 

3-ba1t-10 

5325 

I3t  ' 

5456 

720 

Low 

300-  | 

iiiiiii 

565 

High 

9.06 

Dumb 

8" 

Horizon 

2-batt-18 

iili 

m 

5451 

720 

Low 

300  | 

'  250  ' 

580 

High 

5.98 

Dumb 

8’ 

Horizon 

2-batt-12 

iili 

5419 

720 

Low 

300 

.  U 

470 

High 

5.98 

Smart 

12.5’ 

Humphrey 

3-bat1-18 

6850 

m..  : 

7038 

20 

High 

492 

■ 

913 

Low 

10.77 

Smart 

12.5' 

Humphrey 

3-ba11-12 

8850 

140.'  • 

6990 

20 

Hgh 

432 

j; . 

747 

Low 

10.77 

Smart 

12.5’ 

Humphrey 

3-batt-lO 

111! 

|  tsi  "I 

6981 

20 

High 

492 

HI!! 

757 

Low 

10.77 

Smart 

12.5’ 

Humphrey 

2-bat1-18 

8850' 

y§6 .! 

6976 

20 

High 

1  432 1 

i;-l!260.,!i 

772 

Low 

7.00 

Smart 

12.5' 

Humphrey 

2-batt-12 

6856 

!U  |l 

6944 

20 

High 

492 

Std  '  ' 

662 

Low 

7.00 

Smart 

12.5’ 

Horizon 

3-batt-18 

8850 

188  '  ' 

7038 

720 

Low 

432  ’ 

421 

913 

Low 

10.77 

Smart 

12.5’ 

Horizon 

3-bat1-12 

mi 

'•  US 

6990 

720 

Low 

49? 

'if;. 

747 

Low 

10.77 

Smart 

12.5’ 

Horizon 

3-batt-IO 

6850 

•  •  *31 

6981 

720 

Low 

432 

is"' ' :i 

757 

Low 

10.77 

Smart 

12.5" 

Horizon 

2-batt-18 

iiii 

tat? ' 

6976 

720 

Low 

1.  •  492 

280  , 

772 

Low 

7.00 

Smart 

12.5' 

Horizon 

2-batt-12 

6850  | 

84 

6944 

720 

Low 

492 

111  '2 

662 

Low 

7.00 

Smart 

9' 

Humphrey 

3-batt-18  ' 

6850 

188  •• 

7038 

20 

High 

320 

421  y; ; 

741 

Low 

9.69 

Smart 

9" 

Humphrey 

3-bat1-12 

6850 

140 

6990 

20 

High 

320 

•:255j! 

575 

Low 

9.69 

Smart 

9’ 

Humphrey 

3-batt-IO 

6850 

tat 

6981 

20 

High 

320 

•  285 

585 

Low 

9.69 

Smart 

9’ 

Humphrey 

2-batt-18 

6850  : 

126 

6978 

20 

High 

320 

■  m  I 

600 

Low 

6.38 

Smart 

9" 

Humphrey 

2-batt-12 

6650 

84 

6944 

20 

High 

170 

490 

Low 

6.38 

Smart 

9’ 

Horizon 

3-batt-18 

ilil 

188  ; 

7038 

720 

Low 

lllliil! 

421 

741 

Low 

9.69 

Smart 

9’ 

Horizon 

3-batt-1 2 

6850 

tAO 

6990 

720 

Low 

236 

575 

Low 

9.69 

Smart 

9’ 

Horizon 

3-ball-IO 

6850 

T3t  | 

6981 

720 

Low 

320 

.  "  265 

585 

Low 

9.69 

Smart 

9’ 

Horizon 

2-bati-18 

•6850 

126 

6976 

720 

Low 

l!  320 

\  .280 

600 

Low 

6.38 

Smart 

9’ 

Horizon 

2-batt-12 

6850 

84 

6944 

720 

Low 

320  j 

170 

490 

Low 

6.38 

Smart 

8" 

Humphrey 

3-batt-18 

mil 

t8B 

7038 

20 

Hgh 

300. 

Kill® 

721 

Low 

9.06 

Smart 

8’ 

Humphrey 

3-batt-12 

:':8850 

140 

j  6990 

20 

High 

300 

llllill!; 

555 

Low 

9.06 

Smart 

8' 

Humphrey 

3-batt-IO 

6650 

♦31 

6981 

20 

High 

Si:  3CW  |:. 

265  .  j 

565 

Low 

9.06 

Smart 

8“ 

Humphrey 

2-bat1-18 

iil! 

m 

;  6976 

20 

High 

300 

i  260 

580 

Low 

5.98 

Smart 

8’ 

Humphrey 

2-batt-12 

6650 

94 

j  6944 

20 

High 

300  ' 

170  j 

;  470 

Low 

5.98 

Smart 

8’ 

Horizon 

3-batt-18 

6850 

188 

j  7038 

720 

Low 

300 

421 

!  721 

Low 

9.06 

Smart 

8' 

Horizon 

3-batt-12 

6650 

t40 

6990 

720 

Low 

300 

255 

:  555 

Low 

9.06 

Smart 

8" 

Horizon 

3-batt-IO 

68501 

Hill!! 

j  6981 

720 

Low 

300 

mill 

!  565 

Low 

9.06 

Smart 

8’ 

Horizon 

2-batt-18 

lessol; 

t26 

;  6976 

720 

Low 

900- 

!i  hi 

j  580 

Low 

5.98 

Smart 

8' 

Horizon 

2-batt-12 

■11 

mu 

5  6944 

720 

Low 

lllliii 

17b 

1  470 

Low 

5.98 

F-2 


Table  F.2  Detailed  Design  Raw  Values  (continued) 


SYSTEM  ALTERNA1 

MOTOR  WTEEL  GYRO 

TYPE  SIZE  OPTION 

IVES 

BATTERY 

Mali  Margin 

(ko  under  maximum  of  136k.il 

Power  Margin 

(Available  Watts) 

36  V  Basefino 

Bus  Avail. 

OPTION 

Cwrm 

•itflSwii;::: 

&atV»rw 

Sired* 

TOTAL 

Motor*  Vfiwf* 

llll 

A«to6cnt 

TOTAL 

Dumb 

12.5* 

Humphrey  3-batt-l  8 

■  to 

11 

III 

llll 

1® 

7 

lllil 

lllil 

59 

lit! 

-25 

IHi 

-o.t 

-12 

Bill 

509 

Yes 

Dumb 

12.5* 

Humphrey  3-batt-12 

10 

11 

ill 

♦0 

2 

T 

13 

mm 

66 

-two 

f$S§i;| 

!H1 

-DA 

-12 

648 

185 

Yes 

Dumb 

12.5' 

Humphrey  3-batt-IO 

10 

11.  • 

to 

nil 

7 

t3 

wm 

66 

350 

WM 

III; 

*66 

-0,1 

-12 

640 

77 

Yes 

Dumb 

12.5* 

Humphrey  2-bat1-t8 

!!$§ 

Hill 

;lii 

10 

2 

7 

72 

Wm 

67 

-182 

wm 

1161 

-65 

-DA  ; 

-12 

432 

167 

No 

Dumb 
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Table  F.3  System  Scoring  and  Ranking 


SYSTEM  ALTERNATIVE  I 

SYSTEM  SCORE 
(x  10000) 

MOTORS 

MOM.  WHEELS 

GYRO 

BATT  SYS. 

9"  wheel 

Humphrey 

3-batt-1 8Ahr 

233.74 

Dumb 

9"  wheel 

Horizon 

3-batt-18Ahr 

233.18 

Dumb 

8"  wheel 

Humphrey 

3-batt-18Ahr 

232.75 

Dumb 

8"  wheel 

Horizon 

3-batt-18Ahr 

232.19 

Dumb 

12.5”  wheel 

Humphrey 

3-batt-18Ahr 

224.69 

Dumb 

12.5"  wheel 

Horizon 

3-batt-1 8Ahr 

224.13 

Dumb 

9"  wheel 

Humphrey 

3-batt-12Ahr 

202.58 

Dumb 

9"  wheel 

Horizon 

3-batt-12Ahr 

202.02 

Dumb 

8"  wheel 

Humphrey 

3-batt-12Ahr 

1 99.73 

Dumb 

8"  wheel 

Horizon 

3-batt-1 2Ahr 

199.17 

Dumb 

9"  wheel 

Humphrey 

2-batt-18Ahr 

191.45 

Dumb 

1 2.5"  wheel 

Humphrey 

3-batt-1 2Ahr 

191.43 

Dumb 

9"  wheel 

Horizon 

2-batt-1 8Ahr  . 

190.89 

Dumb 

12.5"  wheel 

Horizon 

3-batt-1 2Ahr 

190.87 

Dumb 

8"  wheel 

Humphrey 

2-batt-18Ahr 

188.60 

Dumb 

8"  wheel 

Horizon 

2-batt-18Ahr 

188.04 

Dumb 

9"  wheel 

Humphrey 

3-batt-1  OAhr 

185.02 

Dumb 

9"  wheel 

Horizon 

3-batt-10Ahr 

1 84.46 

Dumb 

8"  wheel 

Humphrey 

3-batt-10Ahr 

182.17 

Dumb 

8"  wheel 

Horizon 

3-batt-10Ahr 

181.61 

Dumb 

12.5"  wheel 

Humphrey 

2-batt-18Ahr 

181.29 

Dumb 

12.5"  wheel 

Horizon 

2-batt-1 8Ahr 

1  80.73 

Smart 

9"  wheel 

Humphrey 

3-batt-18Ahr 

179.77 

Dumb 

9"  wheel 

Humphrey 

2-batt-12Ahr 

179.76 

Smart 

9"  wheel 

Horizon 

3-batt-1 8Ahr 

179.22 

Dumb 

9"  wheel 

Horizon 

2-batt-1 2Ahr 

179.20 

Smart 

8"  wheel 

Humphrey 

3-batt-1 8Ahr 

176.92 

Dumb 

8"  wheel 

Humphrey 

2-batt-l  2Ahr 

176.91 

Smart 

8"  wheel 

Horizon 

3-batt-18Ahr 

176.36 

Dumb 

8"  wheel 

Horizon 

2-batt-12Ahr 

176.35 

Dumb 

1 2.5"  wheel 

Humphrey 

3-batt-10Ahr 

173.87 

Dumb 

12.5"  wheel 

Horizon 

3-batt-10Ahr 

173.31 

Smart 

12.5"  wheel 

Humphrey 

3-batt-18Ahr 

1 70.73 

Smart 

12.5"  wheel 

Horizon 

3-batt-1 8Ahr 

170.17 

Dumb 

12.5”  wheel 

Humphrey 

2-batt-12Ahr 

1  69.59 

Dumb 

12.5"  wheel 

Horizon 

2-batt-12Ahr 

1 69.04 

Smart 

9"  wheel 

Humphrey 

3-batt-1 2Ahr 

146.76 

Smart 

9"  wheel 

Horizon 

3-batt-12Ahr 

146.20 

Smart 

8"  wheel 

Humphrey 

3-batt-12Ahr 

145.77 

Smart 

8"  wheel 

Horizon 

3-batt-1 2Ahr 

145.21 

Smart 

9"  wheel 

Humphrey 

2-batt-1 8Ahr 

1 37.49 

Smart 

9"  wheel 

Horizon 

2-batt-18Ahr 

136.93 

Smart 

1 2.5"  wheel 

Humphrey 

3-batt-12Ahr 

135.60 

Smart 

12.5"  wheel 

Horizon 

3-batt-12Ahr 

135.05 

Smart 

8"  wheel 

Humphrey 

2-batt-1 8Ahr 

134.63 

Smart 

8"  wheel 

Horizon 

2-batt-1 8Ahr 

134.08 

Smart 

9"  wheel 

Humphrey 

3-batt-1  OAhr 

1 29.20 

Smart 

9"  wheel 

Horizon 

3-batt-1  OAhr 

128.64 

Smart 

8"  wheel 

Humphrey 

3-batt-1  OAhr 

128.21 

Smart 

8"  wheel 

Horizon 

3-batt-10Ahr 

127.65 

Smart 

12.5"  wheel 

Humphrey 

2-batt-l  8Ahr 

127.32 

Smart 

12.5"  wheel 

Horizon 

2-batt-1 8Ahr 

126.76 

Smart 

9"  wheel 

Humphrey 

2-batt-1 2Ahr 

125.79 

Smart 

9"  wheel 

Horizon 

2-batt-12Ahr 

125.24 

Smart 

8"  wheel 

Humphrey 

2-batt-1 2Ahr 

122.94 

Smart 

8"  wheel 

Horizon 

2-batt-12Ahr 

122.39 

Smart 

12.5"  wheel 

Humphrey 

3-batt-10Ahr 

118.05 

Smart 

12.5"  wheel 

Horizon 

3-batt-10Ahr 

117.49 

Smart 

12.5"  wheel 

Humphrey 

2-batt-12Ahr 

115.63 

Smart 

12.5"  wheel 

Horizon 

2-batt-12Ahr 

115.07 
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Appendix  G.  Initial  Controller  Design 

G.l  Overview 

This  appendix  contains  the  controller  gains  and  Matlab  output  graphs  for  the 
various  SIMS  A  T  maneuvers  described  in  Chapter  IV,  Section  4.5  (Command  and  Control 
Architecture).  These  maneuvers  are  NOT  performed  sequentially;  the  SIMS  AT  state  vector 
is  set  to  zero  before  each  maneuver.  This  appendix  only  represents  the  initial  controller 
design  for  an  early  iteration  of  SIMS  AT;  this  appendix  does  not  represent  the  controller 
used  for  the  final  SIMS  AT  design. 


G.2  Gain  Settings  Development 

The  following  pages  list  the  input  gain  matrices  used  in  the  controller  design.  For  each 
set  of  input  gains,  system  output  performance  is  illustrated  using  the  Matlab  simulation. 
Successive  iterations  were  used  to  determine  an  adequate  set  of  gains  to  accomodate  the 
various  SIMSAT  operating  modes.  These  gains  can  be  adjusted  by  the  user  in  actual 
system  operation  as  necessary. 
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Table  G.l  Options  1  and  2  -  Gains 


Initial  Closed-Loop  Controller  Design 


|Qption  #1  (Target  Mode) 


Manvr# 

Command 

(degrees) 

Gain  Matrix 

Ki 

Gain  Matrix 

k2 

Gain  Matrix 

k4 

1 

Roll  = 

-30 

100 

0 

0 

-50 

0 

0 

1 

0 

0 

Yaw  = 

-50 

0 

200 

0 

0 

-50 

0 

0 

1 

0 

Pitch  = 

-10 

0 

0 

1000 

0 

0 

-10 

0 

0 

1 

2 

Roll  * 

5 

1000 

0 

0 

-10 

0 

0 

1 

0 

0 

Yaw  = 

5 

0 

1000 

0 

0 

-50 

0 

0 

1 

0 

Pitch  = 

5 

0 

0 

0 

0 

-10 

0 

0 

1 

3 

Roll  = 

0 

3000 

0 

0 

-10 

0 

0 

1 

0 

0 

Yaw  = 

10 

0 

1000 

0 

0 

0 

0 

1 

0 

Pitch  = 

0 

0 

0 

1000 

0 

0 

-10 

0 

0 

1 

4 

Roll  = 

0 

3000 

0 

0 

-10 

0 

0 

1 

0 

0 

Yaw  = 

90 

0 

300 

0 

0 

-50 

0 

0 

1 

0 

Pitch  = 

0 

0 

0 

0 

0 

-10 

0 

0 

1 

5 

Roll  = 

30 

100 

0 

0 

-50 

0 

0 

1 

0 

0 

Yaw  = 

50 

0 

200 

0 

0 

-50 

0 

0 

1 

0 

Pitch  = 

10 

0 

0 

1000 

0 

0 

-10 

0 

0 

1 

K3  =  0.0585 


|Option  #2  (Target  Mode  with  Roll  Rate) 


Manvr  # 

Command 

(RPM/degrees) 

Gain  Matrix 

Ki 

Gain  Matrix 

k2 

Gain  Matrix 

K4 

■ 

Roll  Rate  = 

1 

0 

0 

0 

1 

0 

0 

0 

0 

Yaw  = 

10 

0 

0 

0 

-50 

0 

0 

1 

0 

Pitch  = 

-5 

0 

0 

0 

0 

-10 

0 

0 

1 

RollRate  = 

9 

0 

0 

0 

1 

0 

0 

40 

0 

0 

Yaw  = 

30 

0 

0 

0 

-50 

0 

0 

1 

0 

Pitch  = 

5 

0 

0 

1500 

0 

0 

-10 

0 

0 

1 

1  ' 

RollRate  = 

-5 

0 

0 

0 

1 

0 

0 

40 

0 

0 

Yaw  « 

20 

0 

0 

0 

-50 

0 

0 

1 

0 

Pitch  = 

10 

0 

0 

1000 

0 

0 

-10 

0 

0 

1 

K3  ~  0.0585 

Note:  1  RPM  =  6  deg/sec 
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Table  G.2  Options  3  and  4  -  Gains 


Initial  Closed-Loop  Controller  Design 


|Qption  #3  (Roll  Spin  Mode) 


Manvr# 

Command 

(RPM) 

Gain  Matrix 

Ki 

Gain  Matrix 

k2 

Gain  Matrix 

K4 

■ 

RollRate  =  1 

0 

0 

0 

1 

0 

0 

20000 

0 

0 

1 

0 

1500 

0 

0 

-50 

0 

0 

1 

0 

■ 

0 

0 

1500 

0 

0 

-10 

0 

0 

1 

Roll  Rate  =  9 

0 

0 

0 

1 

0 

0 

20000 

0 

0 

0 

1500 

0 

0 

-50 

0 

0 

1 

0 

■ 

0 

0 

1500 

0 

0 

-10 

0 

0 

1 

1 

RollRate  =  *5 

0 

0 

0 

1 

0 

0 

20000 

0 

0 

0 

1500 

0 

0 

-50 

0 

0 

1 

0 

0 

0 

1500 

0 

0 

-10 

0 

0 

1 

K3  =  0.0585 


[Option  #4  (Yaw  Spin  Mode) 


Manvr# 

Command 

(RPM) 

Gain  Matrix 

K, 

Gain  Matrix 

k2 

Gain  Matrix 

k4 

1 

YawRate=  1 

2000 

0 

0 

-50 

0 

0 

1 

0 

0 

0 

0 

0 

0 

1 

0 

0 

200000 

0 

0 

0 

1000 

0 

0 

-10 

0 

0 

1 

2 

YawRate-  2 

2000 

0 

0 

-50 

0 

0 

1 

0 

0 

0 

0 

0 

0 

1 

0 

0 

200000 

0 

0 

0 

1000 

0 

0 

-10 

0 

0 

1 

3 

YawRate=  2.6 

2000 

0 

0 

-50 

0 

0 

1 

0 

0 

0 

0 

0 

0 

1 

0 

0 

200000 

0 

0 

0 

1000 

0 

0 

-10 

0 

0 

1 

4 

Yaw  Rate-  -1 

2000 

0 

0 

-50 

0 

0 

1 

0 

0 

0 

0 

0 

0 

1 

0 

0 

200000 

0 

0 

0 

1000 

0 

0 

-10 

0 

0 

1 

5 

YawRate-  -2 

2000 

0 

0 

-50 

0 

0 

1 

0 

0 

0 

0 

0 

0 

1 

0 

0 

200000 

0 

0 

0 

1000 

0 

0 

-10 

0 

0 

1 

6 

YawRate-  -2.6 

2000 

0 

0 

-50 

0 

0 

1 

0 

0 

0 

0 

0 

0 

1 

0 

0 

200000 

0 

0 

0 

1000 

0 

0 

-10 

0 

0 

1 

K3  =  0.0585 


Note:  1  RPM  =  6  deg/sec 
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Table  G.3 


Option  5  -  Gains 


Initial  Closed-Loop  Controller  Design 


|Qption  #5  (Wheel  RPM  Mode)  J 


Manvr  # 

Command 

(RPM) 

Gain  Matrix 

K, 

Gain  Matrix 

K4 

1 

Wheel  1  = 

50 

0 

0 

0 

0 

0 

0 

1 

0 

0 

Wheel  2  = 

20 

0 

0 

0 

0 

0 

0 

0 

1 

0 

Wheel  3  = 

10 

0 

0 

0 

0 

0 

0 

0 

0 

1 

2 

Wheel  1  = 

100 

0 

0 

0 

0 

0 

0 

1 

0 

0 

Wheel  2  = 

0 

0 

0 

0 

0 

0 

0 

0 

1 

0 

Wheel  3  = 

0 

0 

0 

0 

0 

0 

0 

0 

0 

1 

3 

Wheel  1  = 

0 

0 

0 

0 

0 

0 

0 

1 

0 

0 

Wheel  2  = 

100 

0 

0 

0 

0 

0 

0 

0 

1 

0 

Wheel  3  = 

0 

0 

0 

0 

0 

0 

0 

0 

0 

1 

4 

Wheel  1  = 

0 

0 

0 

0 

0 

0 

0 

1 

0 

0 

Wheel  2  = 

0 

0 

0 

0 

0 

0 

0 

0 

1 

0 

Wheel  3  = 

100 

0 

0 

0 

0 

0 

0 

0 

0 

1 

K3  =  0.0585 

Note:  1  RPM  =  0.10471 98  rad/sec 
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Roll(solid),  Yaw(dashed),  and  Pitch(dotted)  Simsat  rollrate(solid),  yawrate(dashed),  pitchrate(dotted) 
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Figure  G.2  Option  1  (Target  Mode)  -  Maneuver  2 


Roll(solid),  Yaw(dashed),  and  Pitch(dotted)  Simsat  rollrate(solid),  yawrate(dashed),  pitchrate(dotted) 
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Figure  G.3  Option  1  (Target  Mode)  -  Maneuver 


Roll(solid),  Yaw(dashed),  and  Pitch(dotted)  Simsat  rollrate(solid),  yawrate(dashed),  pitchrate(dotted) 


Figure  G.4  Option  1  (Target  Mode)  -  Maneuver  4 


Roll(solid),  Yaw(dashed),  and  Pitch(dotted)  Simsat  rollrate(solid),  yawrate(dashed),  pitchrate(dotted) 
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Figure  G.5  Option  1  (Target  Mode)  -  Maneuver  5 


Roll(solid),  Yaw(dashed),  and  Pitch(dotted)  Simsat  rollrate(solid),  yawrate(dashed),  pitchrate(dotted) 


Figure  G.6  Option  2  (Target  Mode  with  Roll  Rate)  -  Maneuver 


Roll(solid),  Yaw(dashed),  and  Pitch(dotted)  Simsat  rollrate(solid),  yawrate(dashed),  pitchrate(dotted) 
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Figure  G.7  Option  2  (Target  Mode  with  Roll  Rate)  -  Maneuver  2 


Roll(solid),  Yaw(dashed),  and  Pitch(dotted)  Simsat  rollrate(solid),  yawrate(dashed),  pitchrate(dotted) 


Time  (sec) 

Figure  G.8  Option  2  (Target  Mode  with  Roll  Rate)  -  Maneuver  3 


Roll(solid),  Yaw(dashed),  and  Pitch(dotted)  Simsat  rollrate(solid),  yawrate(dashed),  pitchrate(dotted) 


Figure  G.9  Option  3  (Roll  Spin  Mode)  -  Maneuver 


Roll(solid),  Yaw(dashed),  and  Pitch(dotted)  Simsat  rollrate(solid),  yawrate(dashed),  pitchrate(dotted) 


Figure  G.10  Option  3  (Roll  Spin  Mode)  -  Maneuver  2 


Roll(solid),  Yaw(dashed),  and  Pitch(dotted)  Simsat  rollrate(solid),  yawrate(dashed),  pitchrate(dotted) 


Figure  G.ll  Option  3  (Roll  Spin  Mode)  -  Maneuver  3 


Roli(solid),  Yaw(dashed),  and  Pitch(dotted)  Simsat  rollrate(soiid),  yawrate(dashed),  pitchrate(dotted) 


Figure  G.12  Option  4  (Yaw  Spin  Mode)  -  Maneuver 


Roll(solid),  Yaw(dashed),  and  Pitch(dotted)  Simsat  rollrate(solid),  yawrate(dashed),  pitchrate(dotted) 


Figure  G.13  Option  4  (Yaw  Spin  Mode)  -  Maneuver  2 


Roll(solid),  Yaw(dashed),  and  Pitch(dotted)  Simsat  rollrate(solid),  yawrate(dashed),  pitchrate(dotted) 


Figure  G.14  Option  4  (Yaw  Spin  Mode)  -  Maneuver  3 


Figure  G.16  Option  4  (Yaw  Spin  Mode)  -  Maneuver  5 


Roll(solid),  Yaw(dashed),  and  Pitch(dotted)  Simsat  rollrate(solid),  yawrate(dashed),  pitchrate(dotted) 
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Figure  G.18  Option  5  (Wheel  RPM  Mode)  -  Maneuver  1 


Roll(solid),  Yaw(dashed),  and  Pitch(dotted)  Simsat  rollrate(solid),  yawrate(dashed),  pitchrate(dotted) 
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Figure  G.19  Option  5  (Wheel  RPM  Mode)  -  Maneuver  2 


Roll(solid),  Yaw(dashed),  and  Pitch(dotted)  Simsat  rollrate(solid),  yawrate(dashed),  pitchrate(dotted) 
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Figure  G.21  Option  5  (Wheel  RPM  Mode)  -  Maneuver  4 


Appendix  H.  Model  Transfer  Procedures 

H.  1  Overview 

This  appendix  describes  the  procedures  required  to  compile  and  download  a  Simu- 
link  model  from  the  ground  station  PC  to  the  AutoBox. 

H.2  Model  Compilation  and  Transfer  Procedures. 

After  creating  a  Simulink  model,  it  should  be  tested  to  ensure  correct  coding  before 
beginning  the  compilation  procedure.  Rim  the  model  within  the  Simulink  environment 
by  selecting  “Start”  from  the  “Simulation”  menu,  or  clicking  on  the  “play”  icon.  Once  the 
coding  errors  have  been  debugged  within  Simulink,  continue  with  the  following  process: 

1.  Power  up  the  AutoBox.  (A  double-beep  will  sound  after  a  few  seconds.) 

2.  From  the  “dSPACE  Files”  window,  select  “Connect  to  Autobox.”  (If  there  was  not  a 
double-beep  following  the  previous  step,  it  should  sound  after  completing  this  step. 
Otherwise,  check  all  power  and  data  connections  and  start  over.) 

3.  From  the  “dSPACE  Files”  window,  select  “Ping  AutoBox.”  A  DOS  window  will 
briefly  appear  indicating  three  to  four  replies  from  the  AutoBox.  If  no  replies  are 
received  (i.e.,  “request  timed  out”),  repeat  the  previous  step.  Otherwise,  check  all 
power  and  data  connections  and  start  over. 

4.  Start  SIMULINK  (using  either  the  “dSPACE  Library”  or  “Simulink”  icons  in  the 
“dSPACE  Files”  window). 

(a)  Open  the  desired  Simulink  model  (*.mdl). 

(b)  From  within  Simulink,  select  “RTW  Build”  from  the  “Tools”  menu,  or  press 
(Ctrl+B),  to  begin  the  compilation  process  (if  the  RTW  Options  have  already 
been  set  correctly).  Otherwise: 

i.  Select  “RTW  Options...”  from  the  “Tools”  menu  (or  select  “Parameters...” 
from  the  “Simulation”  menu). 
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ii.  Check  the  options  on  the  “Solver”  tab.  dSPACE  requires  a  fixed-step  solver 
for  real-time  applications.  (A  fixed  step  size  of  0.001,  using  ode4  or  ode5, 
is  recommended.) 

iii.  If  using  TRACE  and/or  COCKPIT  applications,  the  options  on  the  “Workspace 
I/O”  tab  can  be  ignored. 

iv.  Select  the  “RTW”  tab  and  ensure  all  entries  are  correct: 

•  Code  generation,  System  target  file:  rtil003.tlc 

•  Build  options,  Template  makefile:  rtil003n.tmf 

•  Build  options,  Make  command:  make-rti  board=autobox 

v.  Once  the  above  options  are  set  correctly,  select  “Build”  from  the  “RTW” 
tab. 

5.  The  Real  Time  Workshop  (RTW)  and  Real  Time  Interface  (RTI)  will  then  begin 
the  process  of  compiling  the  Simulink  model  into  C-code,  generating  the  associated 
files,  and  downloading  to  AutoBox. 

The  first  time  a  SlMULINK  model  is  compiled  a  dialog  box  stating  “Error  executing 
build  command:  Error  using  rtw-c”  will  appear.  Within  the  MATLAB  Command 
Window,  the  messages  shown  in  Figure  H.l  will  appear  (for  a  Simulink  model  named 
“example”). 

6.  After  the  above  error  occurs,  open  the  indicated  *.stp  file  within  a  text  editor.  Change 
the  text  from  “AutoBox”  to  “DS1003”  and  save  the  *.stp  file  with  the  same  name. 

7.  Rebuild  the  model  following  the  same  process  in  Step  4(b)  above.  The  messages 
shown  in  Figure  H.2  will  appear  in  the  Matlab  Command  Window  indicating  a 
successful  download.  (To  avoid  the  above  error  from  occurring  with  future  changes 
of  the  Simulink  model  use  the  same  filename.) 
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***  Starting  RTI  build  procedure  with  RTI1003  3.1  (28-Apr-1998) 

###  Starting  RTW  build  procedure  for  model:  example 
###  Invoking  Target  Language  Compiler  on  example. rtw 

tic  — r  example. rtw  c:\dsp_cit\matlab\rtil003\tlc\rtil003.tlc  -O.  - 

Ic : \dsp_cit\matlab\rtil003\tlc  -IC : \MATLAB\rtw\c\tlc  -aInlineParameters=0 

###  creating  project  marker  file:  rtw__pro j  .tmw 

###  Creating  example. mk  from  rtil003n.tmf 

###  Building  example:  dsmake  -f  example. mk  board=autobox 

BUILDING  PROGRAM  (single  timer  task  mode) 

Initial  SimState:  default  (defined  in  srtframe.c) 

[srtframe.c] 

[example. c] 

[rt_sim.  c] 

[ode4 . c] 

LINKING  PROGRAM  . . . 

LOADING  PROGRAM  - 

MON40NET  -  DS1003  Processor  Board  Monitor,  Vs  5.4  -  32,  (C)  1997  by  dSPACE  GmbH 

DS1003  -  autobox  -  I/O  [0318H]  -  €4  KB  at  [ODOOOOH] 

1024  KW  local  RAM  (bankO) ,  0  KW  local  RAM  (bankl) ,  256  KW  global  RAM 

Searching  DS1003  peripherals  . . . 

Loading  system  setup  . . . 

Loading  setup  example . stp  . . . 

Error  reading  setup  file  example. stp. 

Error  loading  setup . 

DSP  not  started. 

OPUS  MAKE:  Shell  line  exit  status  1  (ignored) 

DOWNLOAD  ABORTED 


Figure  H.l  Error  Messages 
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***  Starting  RTI  build  procedure  with  RTI1003  3-1  (28-Apr-1998) 

###  Starting  RTW  build  procedure  for  model:  example 

###  Invoking  Target  Language  Compiler  on  example. rtw 

tic  -r  example. rtw  c:\dsp_cit\matlab\rtil003\tlc\rtil003.tlc  -O.  - 

Ic : \dsp_cit\matlab\rtil003\tlc  -IC : \MATLAB\rtw\c\tlc  -aInlineParameters=0 

###  example. mk  which  is  generated  from  rtil003n.tmf  is  up  to  date 

###  Building  example:  dsmake  -f  example. mk  board=autobox 

BUILDING  PROGRAM  (single  timer  task  mode) 

Initial  SimState:  default  (defined  in  srtframe.c) 

[srtframe.c] 

[example . c] 

[rt_sim.  c] 

[ode4 . c] 

LINKING  PROGRAM  .  .  . 

LOADING  PROGRAM  .  .  . 

MON40NET  -  DS1003  Processor  Board  Monitor,  Vs  5.4  -  32,  (C)  1997  by  dSPACE  GmbH 

DS1003  -  autobox  -  I/O  [0318H]  —  64  KB  at  [0D0000H] 

1024  KW  local  RAM  (bankO) ,  0  KW  local  RAM  (bankl) ,  256  KW  global  RAM 

Searching  DS1003  peripherals  . . . 

Loading  system  setup  . . . 

Loading  setup  example . stp  . . . 

Loading  object  module  example. obj  ... 

DSP  started  . . . 

DOWNLOAD  SUCCEEDED 

###  Successful  completion  of  RTW  build  procedure  for  model:  example 
***  Finished  RTI  build  procedure  for  model  example 


Successful  Download  Messages 
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Figure  H.2 


8.  With  a  successful  download,  the  above  process  is  not  required  to  reload  the  compiled 
model  after  a  power-down.  After  restarting  AutoBox,  follow  these  steps: 

(a)  From  the  “dSPACE  Files”  window,  select  “Monitor”  to  run  the  MON40NET 
program.  A  DOS  window  will  appear  with  “DSP  is  RESET”  followed  by  several 
options.  Select  “Load  object  module”  by  typing  a  1  at  the  prompt. 

(b)  At  the  prompt  “Enter  the  filename  of  object  module  (without  suffix)”  type  the 
name  of  the  *.obj  file  (for  the  compiled  model)  with  its  full  path  and  press  enter. 

(c)  Select  “Restart  DSP”  by  typing  a  2  at  the  prompt.  “DSP  is  RUNNING”  will 
appear  above  the  menu,  indicating  that  the  program  js  now  running  on  AutoBox. 
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Appendix  I.  Designing  the  User 

Interface 

1. 1  Overview 

This  appendix  describes  the  procedures  required  to  link  SlMULINK  variables  with 
Trace  and  Cockpit  applications.  The  following  sections  outline  the  process  of  imple¬ 
menting  the  user- interface  software  once  a  properly  working  Simulink  model  is  successfully 
compiled  and  downloaded  to  the  AutoBox. 

1.2  Trace. 

1.  From  the  “dSPACE  Files”  window,  select  the  “Trace”  icon.  (If  the  PC  is  not  currently 
communicating  with  the  operating  AutoBox,  an  error  message  will  display.  This  can 
be  ignored  for  design  purposes,  but  the  simulation  program  must  be  running  on 
the  AutoBox  and  communicating  with  the  ground  station  PC  to  receive  real-time 
updates  of  plotting  data.) 

2.  Two  windows  will  open:  the  “TRACE  Net  Control  Panel,”  containing  the  tools  for 
linking  the  command  and  control  variables  with  Trace  plots,  and  the  “Trace  Plots” 
window,  containing  the  graphing  area. 

3.  The  last  Trace  files  used  in  both  windows  will  automatically  open  by  default.  The 
“File”  menu  on  the  Control  Panel  can  be  used  to  open  other  previously  created  files. 
To  create  a  new  Trace  set-up,  follow  these  steps: 

(a)  Select  “Load  Trace  File...”  from  the  “File”  menu  or  click  on  the  first  icon  on 
the  Control  Panel  toolbar. 

(b)  Find  the  Trace  file  (*.trc)  corresponding  to  the  compiled  real-time  or  simula¬ 
tion  program  that  will  be  running  on  AutoBox  and  open  it.  This  *.trc  filename 
should  appear  below  the  menu  toolbars,  followed  by  the  path  to  the  folder 
containing  this  file  and  all  the  other  files  created  by  the  compilation  process. 
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(c)  Once  the  Trace  file  is  loaded,  two  Control  Panel  windows  will  display  the  tree 
structure  of  the  corresponding  simulation  code.  The  small  window  simply  shows 
the  entire  structure,  while  the  large  center  window  zooms  in  on  the  tree  to  allow 
access  to  the  model  structure. 

(d)  Click  within  the  large  tree  structure  window  at  the  center  of  the  Control  Panel 
and  find  the  “Model  Root”  block.  Select  this  block  to  display  a  list  of  simulation 
variables  on  the  right  side  of  the  Control  Panel.  The  variable  names  are  preceded 
by  one  of  the  following  letters: 

•  L  =  labeled  signal 

•  B  =  block  output 

•  S  =  input  of  signal  sink 

•  P  =  block  parameter 

(e)  From  this  variable  list,  select  the  desired  signal  to  plot  in  the  graphing  display. 
Output  blocks  in  the  original  Simulink  code  correspond  to  variables  preceded 
by  an  “S,”  so  ensure  the  variables  chosen  for  Trace  display  have  an  “S”  in 
front  of  the  variable  name. 

(f)  After  clicking  on  the  desired  signal  variable,  a  graphing  window  for  this  variable 
should  appear  on  the  plotting  screen.  With  a  signal  to  plot,  a  Trace  “template” 
file  can  be  created  to  store  the  desired  graphing  options  for  the  user  interface. 

(g)  Return  to  the  Control  Panel  and  select  the  other  signals  to  plot.  If  it  is  desired 
to  plot  multiple  signals  on  a  single  graph,  initially  only  select  one  variable  per 
plot  to  establish  the  graphing  window.  Once  all  signals  have  been  selected  (or 
one  variable  of  a  multiple  signal  plot),  arrange  the  graphing  windows  as  desired 
within  the  Trace  plots  screen. 

(h)  General  graphing  features  can  be  selected  under  the  “Options”  menu  of  the 
plotting  screen.  For  example,  a  grid  can  be  placed  on  the  graph  and  “Scaling 
of  Axes...”  can  be  used  to  set  upper  and  lower  bounds  of  the  graph  or  choose 
“Floating”  to  automatically  rescale  based  on  the  current  data  capture. 
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(i)  To  plot  multiple  signals  on  one  graph,  select  “Reference...”  under  the  “Options” 
menu  of  the  plotting  screen.  This  process  is  similar  to  the  initial  signal  selection 
from  the  Control  Panel.  Use  the  “tree”  window  to  find  the  “model  root.”  Within 
the  list  of  variables  on  the  right,  the  initial  signal  selection  will  have  a  block 
marking  it.  Simply  select  any  other  variables  to  plot  on  the  same  graph  and 
return  to  the  plotting  screen.  A  small  box  at  the  lower  left  of  the  current  graph 
can  be  selected  to  show  the  signals  to  be  plotted,  and  their  corresponding  line 
colors. 

(j)  After  completing  the  process  of  selecting  the  desired  signals  to  plot,  and  design¬ 
ing  the  Trace  Plots  window  to  the  user’s  preference,  ensure  the  template  is 
saved  under  the  “File”  menu. 

(k)  Once  the  desired  Trace  file  (*.trc)  and  template  (*.tpl)  are  open  within  the 
Trace  environment,  check  the  rest  of  the  Trace  options  on  the  Control  Panel. 
The  interval  length  of  real-time  data  capture  can  be  selected  in  the  lower  left 
of  the  Control  Panel.  This  allows  near  instantaneous  variable  updates,  however 
a  length  of  10  seconds  is  recommended  to  provide  frequent  updates,  but  with 
more  data  displayed  at  a  time.  Upon  finishing  the  set-up  of  the  Trace  envi¬ 
ronment  the  settings  must  be  saved  by  selecting  “Save  Experiment...”  from  the 
Control  Panel  “File”  menu.  The  current  TRACE  file,  template,  and  settings  will 
automatically  display  the  next  time  Trace  is  started  unless  a  new  experiment 
is  opened. 

4.  Before  beginning  a  simulation  or  real-time  application,  check  to  make  sure  the  desired 
Trace  files  are  being  used.  The  *.trc  file  corresponding  to  the  program  running  on 
AutoBox  should  be  shown  below  the  Control  Panel  toolbar,  along  with  the  proper 
directory  path.  The  current  template  will  be  listed  at  the  top  of  the  Trace  Plots 
screen.  The  loaded  experiment  file  (*.exp)  will  be  listed  at  the  bottom  of  both 
screens. 

5.  When  all  the  above  steps  have  been  successfully  completed,  Trace  is  ready  to  display 
telemetry.  If  the  simulation  or  real-time  application  is  running  on  AutoBox,  and 
communication  links  are  working,  selecting  “Start”  in  the  TRACE  windows  will  begin 
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data  capture  and  plotting.  Selecting  “Auto”  (next  to  “Start”  in  the  plotting  window 
and  below  “Start”  on  the  Control  Panel)  allows  automatic  updating  of  plots  according 
to  the  defined  interval  length.  If  “Auto”  is  not  selected,  the  user  must  manually  select 
when  to  conduct  a  data  capture.  To  stop  TRACE  telemetry  monitoring,  simply  select 
“Stop.” 

6.  Following  a  telemetry  monitoring  session,  Trace  plot  data  can  be  saved  to  a  Mat- 
lab  *.mat  file  using  the  “Save  Current  Capture...”  option  on  the  “File”  menu  of  the 
Control  Panel.  This  *.mat  file  is  then  available  to  graph  the  results  in  Matlab  at  a 
later  time,  according  to  user  needs. 

1.3  Cockpit. 

1.  From  the  “dSPACE  Files”  window,  select  the  “Cockpit”  icon.  (If  the  PC  is  not 
currently  communicating  with  the  operating  AutoBox,  an  error  message  will  display. 
This  can  be  ignored  for  design  purposes,  but  the  simulation  program  must  be  running 
on  the  AutoBox  and  communicating  with  the  ground  station  PC  to  use  Cockpit  for 
command  and  control.) 

2.  The  “COCKPIT  Net”  window  will  open.  At  the  top  are  the  menu  and  toolbar  for 
designing  the  graphical  user  interface.  The  area  below  the  menus  is  available  for 
positioning  input  and  output  control  and  display  instruments. 

3.  Use  the  “File”  menu  to  open  a  previously  created  file.  Otherwise,  follow  these  steps 
to  create  a  new  COCKPIT  display: 

(a)  Select  “Load  Trace  File...”  from  the  “File”  menu  or  click  on  the  corresponding 
toolbar  icon. 

(b)  Find  the  Trace  file  (*.trc)  corresponding  to  the  compiled  real-time  or  simula¬ 
tion  program  that  will  be  running  on  AutoBox  and  open  it.  This  *.trc  filename 
should  appear  below  the  menu  toolbars,  followed  by  the  path  to  the  folder 
containing  this  file  and  all  the  other  files  created  by  the  compilation  process. 
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(c)  Once  the  Trace  file  is  loaded,  design  of  ground  controls  can  begin.  Under 
the  “Options”  menu  a  “Quick  Control”  toolbox  can  be  selected  for  display,  in 
addition  to  the  standard  toolbar,  or  Cockpit  instruments  can  be  accessed  from 
the  “Control”  menu. 

(d)  Select  a  control  instrument  in  one  of  the  ways  listed  above.  Once  a  specific 
control  is  selected,  it  can  be  placed  anywhere  in  the  empty  window  and  sized 
as  desired.  This  instrument  will  continue  to  be  drawn  until  another  type  is 
selected. 

(e)  Double-click  on  an  instrument  placed  in  the  design  area  to  open  its  parameter 
dialog  box.  The  application  program’s  tree  structure  will  be  displayed,  just  as 
on  the  Trace  Control  Panel. 

(f)  Click  within  the  large  tree  structure  and  select  the  “Model  Root”  block. 

(g)  From  the  variable  list  on  the  right,  select  the  desired  variable  to  link  to  the 
control  instrument.  Input  blocks  in  the  original  SlMULlNK  code  correspond  to 
variables  preceded  by  a  “B,”  so  ensure  a  variable  chosen  for  sending  commands 
has  a  “B”  in  front  of  the  variable  name.  Just  as  in  Trace,  use  a  variable 
preceded  by  an  “S”  for  a  display  instrument. 

(h)  Depending  on  the  type  of  control  instrument  selected,  other  parameter  entries 
are  made.  For  example,  the  initial  value  (origin)  of  a  variable  and  its  maximum 
and  minimum  commanded  values  can  be  set.  These  parameter  choices  will  be 
reflected  in  a  graphical  instrument  upon  returning  to  the  main  window. 

(i)  Once  all  instruments  have  been  selected  (ensure  parameters  are  properly  de¬ 
fined),  arrange  them  as  desired  for  the  user  interface. 

(j)  The  method  of  obtaining  initial  values  when  starting  a  simulation  can  be  defined 
using  the  “Setup”  menu. 

(k)  Save  the  Cockpit  instrument  layout  as  a  *.ccs  file,  which  allows  it  to  be 
reloaded  in  the  future. 

4.  Before  beginning  a  simulation  or  real-time  application,  check  to  make  sure  the  desired 
Trace  files  are  being  used.  The  *.trc  file  corresponding  to  the  program  running 
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on  AutoBox  should  be  shown  below  the  menu  and  toolbar,  along  with  the  proper 
directory  path.  The  loaded  instrument  set-up  file  (*.ccs)  will  be  listed  at  the  top  of 
the  window. 

5.  When  all  the  above  steps  are  complete,  the  Cockpit  user  interface  is  ready  for 
operation.  If  the  simulation  or  real-time  application  is  running  on  AutoBox,  and 
communication  links  are  working,  select  “Start”  on  the  toolbar  or  from  the  “Anima¬ 
tion”  menu. 
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Appendix  J .  Design  and  Operation  of 
RealMotion  Interface 

J.  1  Overview 

This  appendix  describes  the  design  and  operation  of  the  RealMotion  3-D  animation 
tool.  RealMotion  is  a  dSPACE  software  product  allowing  visualization  of  SIMSAT 
motion  real-time,  as  well  as  post-mission  (or  simulated  from  data).  A  separate  PC  is 
required  to  run  the  RealMotion  software. 


J.2  Software  Links. 

The  design  process  included  modifying  C-code  generated  by  the  dSPACE  compilation 
of  Simulink,  creating  a  geometric  model,  and  developing  its  associated  scene  control  file. 
The  operation  of  RealMotion  required  locating  the  DSP  card  to  load  the  necessary 
simulation  files,  and  starting  the  3-D  animation  by  opening  RealMotion.  The  following 
steps  outline  how  the  SlMULlNK-designed  code  was  modified  for  use  with  RealMotion. 

1.  The  header  file  rmproto.h  was  included  in  the  application  C-code. 

2.  The  snapshot  buffer  was  defined  according  to  the  variables  of  the  software.  This 
block  of  code  is  necessary  to  ensure  RealMotion  preserves  enough  memory. 

3.  The  snapshot  function  is  used  to  “freeze”  model  variables  by  storing  them  consistently 
into  the  snapshot  buffer. 

4.  The  transformation  function  calculates  the  translation  vectors  and  the  rotation  ma¬ 
trix  for  each  of  the  model  members.  The  “frozen”  snapshot  buffer  data  are  copied 
to  local  variables  from  which  the  motion  data  of  the  members  are  derived. 

5.  The  rm-init-interface  call  is  the  main  initialization  function  of  RealMotion.  The 
parameters  for  this  section  of  code  include  the  number  of  members,  the  name  of 
the  transformation  function,  the  name  of  the  snapshot  function,  and  the  size  of  the 
snapshot  buffer. 
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6.  The  rm-set-member-name  is  an  optional  call  used  to  store  legible  names  for  each 
member  together  with  the  motion  data  in  order  to  easily  identify  the  motion  data 
structures  in  RealMotion. 

7.  The  snapshot  call  is  used  to  call  the  rm-snapshot  macro  from  within  the  model’s 
real-time  section. 

8.  The  rm-service-realmotion  call  is  used  to  call  the  rm-service-realmotion  macro  from 
within  the  background  task. 

The  above  steps  can  be  reaccomplished  with  each  new  version  of  software  architec¬ 
ture.  However,  since  RealMotion  is  simply  displaying  the  change  in  orientation  variables, 
which  will  always  be  available,  a  one-time  file  modification  can  be  made.  Adding  the  above 
code  segments  to  the  *.usr  file  will  allow  new  versions  of  command  and  control  software  to 
be  created,  without  having  to  add  the  above  code  every  time. 

J.  3  Scene  Control. 

Example  code  segments  of  a  RealMotion  Scene  Control  File  affecting  all  animations: 

RAMSIZE  =  800000 
NFRAMES  =  1500 
STARTFRAME  =  1 
STEPFRAME  =  1 

RESULT  =  ORIENTATION,  %ONLINE 

GPOLYGON  =  TRUE 
BACKGROUND  =  1,  1,  0.705 


General  data  for  all  windows: 

RAMSIZE  =  800000  sets  the  memory  allocation  (limit=2,000,000  bytes). 
NFRAMES  =  1500  gives  the  total  number  of  displayed  frames  (max=1500). 
STARTFRAME  =  1  establishes  the  first  frame  to  display. 
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STEPFRAME  =  1  defines  the  step  size  of  the  frame  counter. 


RESULT  =  ORIENTATION,  %ONLINE  indicates  that  real-time  motion  data  retrieval 
will  be  used  during  the  animation,  rather  than  an  off-line  data  file.  The  result  filename 
(ORIENTATION)  links  the  motion  data  with  the  geometric  model  components. 

Window  dependent  data: 

GPOLYGON  =  TRUE  displays  all  components  of  the  geometric  model  as  polygons. 
BACKGROUND  =  1,  1,  0.705  sets  the  background  color,  in  terms  of  amount  red,  green, 
and  blue  (from  0  to  1  each),  i.e.  this  background  is  a  light  yellow. 


Example  of  code  to  define  a  graphical  *.dxf  file  “member”  (a  SIMSAT  component): 

MEMBER  =  ARM1,  SIMSAT.DXF,  1 
FORMAT  =  DXF 
MAPPING  =  TRUE 
MOTIONRESULT  =  ORIENTATION,  1 
RGB  =  1,  1,  0 
WIRE  =  TRUE 


MEMBER  =  ARM1,  SIMSAT.DXF,  1  defines  the  name  of  the  graphical  object  (ARM1), 
the  *.dxf  file  to  use  (SIMSAT.DXF),  and  the  object’s  number  (if  more  than  one). 
FORMAT  =  DXF  is  the  format  of  the  geometry  file. 

MAPPING  =  TRUE  allows  use  of  automatic  centering  and  distance  adaptation. 
MOTIONRESULT  =  ORIENTATION,  1  names  the  file  for  motion  result  data  (orienta¬ 
tion,  mdf). 

RGB  =  1,  1,  0  assigns  the  color  of  the  object  (red,  green,  and  blue)  based  on  the  intensity 
(0-1),  i.e.  this  member  is  yellow. 

WIRE  =  TRUE  indicates  a  wire  model  representation. 
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(The  above  code  segment  is  repeated  for  the  other  SIMSAT  members,  with  appropriate 
modifications.  For  example,  different  colors  can  be  assigned  to  members  on  opposite  sides 
to  allow  easier  identification  of  a  side  during  animation.  Each  member  should  also  be 
given  a  short,  descriptive  name.  The  name  will  appear  in  the  Member  List  of  the  display 
window’s  “Member”  menu.  This  can  be  used  to  select  a  member  and  modify  its  attributes 
directly  from  the  display  window,  without  changing  the  default  scene  control  file.) 

Example  of  code  to  define  an  “Observer”  perspective: 

OBSERVER  =  REMOTE-PILOT,  FIXED,  INERTIAL 

ACENTER  =  TRUE 

DISTANCE  =  1 

ROFFSET  =  90,  0,  0 

VIEWRoffset  =  1,  1,  1 

VIEWToffset  =  1,  1,  1 

ZOOM  =  1.5 

OBSERVER  =  REMOTE-PILOT,  FIXED,  INERTIAL  names  the  observer  (remote-pilot) 
and  sets  the  reference  frame  fixed  in  inertial  space. 

ACENTER  =  TRUE  sets  automatic  centering  for  all  members,  preventing  them  from  being 
moved  with  the  mouse. 

DISTANCE  =  1  represents  a  distance  scaling  factor  (greater  than  1  increases  the  distance, 
less  than  1  decreases  the  distance),  i.e.  DISTANCE  =  2  halves  the  picture  size. 
ROFFSET  =  90,  0,  0  provides  the  basic  rotation  (pivoting  of  observer)  around  the  axes, 
i.e.  this  observer  is  rotated  about  the  x-axis  to  provide  a  side-view  of  the  object. 
VIEWRoffset  =  1,  1,  1  is  the  pivoting  angle  of  the  scene. 

VIEWToffset  =  1,  1,  1  is  the  translation  of  the  scene. 

ZOOM  =  1.5  is  a  zoom  angle  factor  (greater  than  1  increases  the  zoom  angle,  less  than  1 
decreases  the  zoom  angle),  i.e.  ZOOM  =  2  halves  the  picture  size. 

(Up  to  eleven  different  “observers”  can  be  defined.  The  point-of-view  for  observing 
can  then  be  chosen  from  the  “Observer”  menu  of  the  display  window.) 
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Using  one  of  the  following  sets  of  steps  accesses  the  RealMotion  DSP  card,  loads  the 
necessary  files,  and  gets  the  animation  running. 

1.  Change  the  active  path  to  the  directory  containing  the  dSPACE  and  RealMotion 
files  for  the  desired  application. 

2.  Type  “mon40  name-of-file  -B  RealMot”. 

3.  Start  the  RealMotion  application  by  selecting  “RealMotion  ”  from  the  “dSPACE 
Files”  window. 

4.  Load  the  desired  scene  control  file  (i.e.,  Simsat.ctl). 

Equivalent  process: 

1.  Select  the  “Monitor”  icon  in  the  “dSPACE  Files”  window. 

2.  From  the  MON40  menu,  select  [1]  Load  object  module. 

3.  Type  desired  path  and  filename. 

4.  The  MON40  menu  should  reappear.  If  not,  check  to  make  sure  that  the  desired  file 
and  directory  exist,  and  retry  the  previous  steps. 

5.  Select  [2]  Restart  DSP. 

6.  Start  RealMotion. 

7.  Load  the  desired  scene  control  file  (i.e.  Simsat.ctl). 

Animation  should  begin  automatically. 
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Appendix  K.  Final  Structural  Design 

K.l  Overview 

This  appendix  describes  the  detailed  design  of  the  SIMSAT  structure.  Using  the 
AutoCAD  and  3D  Studio  VIZ  software  packages,  structural  evolution  progressed  from 
initial  concepts  and  sketches  to  detailed  drawings  suitable  for  system  fabrication.  The 
figures  at  the  end  of  this  appendix  are  copies  of  the  design  drawings  submitted  to  the 
AFIT  Fabrication  Shop. 

The  following  pages  describe  in  detail  the  structural  elements  of  the  SIMSAT  design. 
Rationale  for  these  design  decisions  is  also  presented. 

K.2  Structural  Design 

The  SIMSAT  structure  supports  individual  components  and  acts  as  a  skeleton  for  the 
entire  system.  The  SIMSAT  structure  consists  of  two  box  trusses  attached  to  the  mounting 
arms  of  the  central  air-bearing  assembly.  Aluminum  and  steel  are  used  almost  exclusively 
as  construction  materials,  with  lexan  used  as  a  cover  surrounding  the  momentum  wheel 
assembly.  Maximum  use  of  standard  components  and  interfaces  within  the  structural 
design  allows  for  increased  modularity  and  the  ability  to  reconfigure  SIMSAT  to  meet 
changed  requirements.  Modular  design  also  provides  for  easy  access  to  items  (such  as 
batteries)  which  must  be  removed  or  serviced  between  experiments. 

The  baseline  SIMSAT  structure  (baseplates,  mounting  plates  and  8  support  rods)  has 
a  total  mass  of  approximately  37.5  kg.  This  mass  represents  an  upper  limit  and  does  not 
reflect  the  effect  of  follow-on  efforts  to  reduce  structural  mass  through  the  use  of  thinner 
mounting  plates,  lightening  holes,  or  better-optimized  structural  members. 

Each  side  of  the  SIMSAT  structure  is  based  upon  a  box  truss  construction  using 
standard  plates  and  stringers.  Each  truss  is  mounted  to  the  air-bearing  with  an  aluminum 
7075-T7  collar.  Each  cylindrical  collar  has  an  outer  diameter  of  4.875”  and  a  height  of  2”. 
A  2”  diameter  hole  with  3/16”  deep  counterbore  (3”  diameter)  is  centered  on  the  circular 
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face  of  the  collar  to  allow  for  cable  routing  through  the  hollow  mounting  shafts  and  central 
sphere. 

Base  plates  allow  for  the  attachment  of  each  truss  to  its  respective  collar,  and  mount¬ 
ing  plates  provide  attachment  points  for  individual  components.  A  standard  template  is 
used  for  all  plates,  which  are  available  in  a  variety  of  thicknesses  (1/2”,  1/4”,  3/16”,  1/8”, 
and  3/32”).  Aircraft-grade  aluminum  is  used  in  all  instances:  aluminum  7075-T6  for  1/8” 
and  3/16”  plates,  aluminum  7075-T7  for  3/32”  plates,  and  aluminum  2024  for  1/2”  and 
3/32”  plates.  The  base  (innermost)  plates  are  1/2”  thick  and  are  connected  to  the  truss 
attachment  collars;  component  mounting  plates  may  be  thinner  to  reduce  structural  weight 
if  load  limits  are  not  exceeded. 

All  plates  are  53  cm  (20.866”)  tall  by  35  cm  (13.78”)  wide.  The  53  cm  height  and 
35  cm  width  of  the  plates  were  chosen  for  several  reasons: 

•  To  allow  room  for  mounting  the  Autobox  to  a  plate  in  a  vertical  direction. 

•  To  provide  adequate  height  to  mount  the  five-sided  lexan  box  to  a  plate  and  still 
have  the  box  clear  the  momentum  wheels. 

•  To  provide  adequate  room  to  mount  three  motor  amplifiers  (controllers)  on  one  side 
of  a  plate. 

•  To  provide  space  to  mount  two  batteries  on  one  side  of  a  plate. 

•  To  make  all  plates  a  standard  size  so  the  SIMS  AT  truss  is  symmetrical. 

Four  1”  diameter  holes  are  located  on  the  corners  of  each  plate  with  centers  offset  4.4 
cm  (1.732”,  vertically  and  horizontally)  from  the  outer  edgeline.  These  holes  allow  the 
mounting  plates  to  slide  onto  the  main  steel  support  rods.  Four  10-32  threaded  holes 
(centers  located  0.5”  in  vertically  and  horizontally  from  edgeline)  provide  mounting  points 
for  L-bracket  attachments.  These  L-brackets  allow  for  diagonal  cross-members  to  be  at¬ 
tached  between  mounting  plates.  Diagonal  cross-members  are  not  included  in  the  baseline 
SIMS  AT  design,  but  can  be  added  to  provide  additional  stiffness  if  improved  vibratory 
response  is  required. 
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The  main  truss  support  rods  are  60  cm  (23.6”)  long  with  an  outer  diameter  of  1” 
and  a  wall  thickness  of  0.065”.  Each  of  the  eight  rods  is  constructed  from  stainless  steel 
316  tubing  with  one  end  plugged  with  a  metal  insert.  The  plugged  end  of  each  rod  is 
placed  through  the  base  plate  and  mated  with  a  connecting  bolt  to  secure  the  rod  in  place. 
This  arrangement  allows  for  minimal  protrusion  on  the  inside  of  the  base  plate,  thereby 
lessening  interference  with  the  overall  SIMS  AT  pitch  envelope. 

Since  bending  deflection  of  a  rod  is  dependent  upon  its  inertia,  a  hollow  tube  (with 
its  mass  concentrated  near  its  outer  diameter)  has  a  better  stiffness  to  weight  ratio  than 
a  solid  rod.  The  60  cm  length  of  the  rods  offers  support  for  the  baseline  components  and 
provides  8  to  10  cm  of  excess  length  for  possible  future  components.  Rods  with  1”  outer 
diameter  and  0.065”  wall  thickness  were  chosen  in  part  because  these  dimensions  were  a 
standard  tube  size  available  in  vendor  catalogs.  The  CADRE  analysis  discussed  earlier 
showed  these  rods  to  have  adequate  strength  and  vibratory  stiffness. 

The  mounting  plates  are  fixed  to  their  positions  along  the  support  rods  through  the 
use  of  metal  clamp-on  collars  (with  a  1”  bore  hole).  Each  mounting  plate  has  a  total  of 
eight  collars  (one  collar  for  each  side  of  the  four  mounting  holes)  to  prevent  movement  of 
the  mounting  plate  along  the  support  rod.  Mounting  plates  can  be  adjusted  and  secured 
to  different  points  along  the  support  rods  to  accommodate  equipment  changes  and/or 
gross  balance  requirements.1  One-piece  collars  are  used  primarily  for  mounting  plates  not 
subject  to  frequent  adjustment,  while  two-piece  collars  allow  for  easy  take-on/take-off  in 
situations  where  access  is  routinely  required.  Each  collar  is  made  from  aluminum;  a  two 
piece  collar  weighs  0.04  kg  and  a  one  piece  collar  weighs  0.035  kg  (weight  includes  the  cap 
screws).  The  cap  screws  used  to  tighten  the  clamp-on  collars  are  manufactured  from  alloy 
steel. 

The  payload  plate  is  the  mounting  plate  furthest  from  the  central  sphere  located  on 
the  AutoBox  side  of  SIMS  AT.  This  1/4”  thick  mounting  plate  is  identical  to  a  standard 
mounting  plate,  with  the  addition  of  212  threaded  holes  (5/16”  diameter)  spaced  1”  apart 

JThe  current  location  of  mounting  plates  in  the  SIMS  AT  baseline  includes  cabling  space  to  meet  nomimal 
wire  bend  requirements.  These  estimates  are  conservative  and  may  allow  for  closer  spacing  of  plates 
following  actual  hardware  integration. 
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(horizontally  and  vertically)  between  centers.  These  holes  are  referred  to  collectively  as 
a  ’pegboard’  surface.  The  pegboard  allows  the  user  to  attach  experimental  payloads  or 
balancing  weights  along  the  payload  plate  with  a  maximum  amount  of  flexibility.  Carbon 
steel  blocks  of  nominal  5  kg  and  1  kg  masses  allow  for  gross  balancing  of  the  SIMS  AT 
structure.  These  blocks  can  be  attached  to  the  pegboard  using  5/16”  bolts.  Experiments 
can  be  attached  directly  to  the  pegboard  with  bolts  or  indirectly  using  mounting  brackets 
attached  to  the  experiment. 

In  addition  to  carbon  steel  blocks  attached  to  the  payload  plate,  gross  SIMSAT 
balancing  can  be  accomplished  with  53cm  by  35cm  steel  counterweight  plates.  Four  2  kg 
counterweight  plates  are  available  and  four  5  kg  plates  are  available.  These  plates  are  cut 
from  the  standard  plate  template  except  they  have  lightening  holes  to  provide  the  specified 
mass.  The  2  kg  plates  are  nominally  1/16”  thick  with  a  6.72”  diameter  hole  in  the  center. 
The  5  kg  plates  are  nominally  3/16”  thick  with  a  9.9”  hole  in  the  center.  These  plates 
give  the  user  flexibility  to  place  counterweight  near  to  the  base  plate  (closer  in  towards  the 
central  sphere)  to  reduce  inertia  penalties.  Since  inertia  varies  with  the  square  of  distance, 
placing  dense  counterweight  plates  near  the  central  sphere  results  in  a  lower  moment  of 
inertia  (and  better  yaw  performance)  than  placing  light  objects  at  a  further  distance  from 
the  sphere. 

Fine-tuning  of  SIMSAT  balance  is  accomplished  with  a  counterweight  mechanism. 
The  counterweight  mechanism  can  be  mounted  on  either  side  of  SIMSAT  depending  on 
balancing  needs.  This  mechanism  relies  upon  orthogonal  1/4”  stainless  steel  threaded 
rods,  hollow  cylindrical  weights  (each  with  a  1/4”  hole),  and  small  steel  clamp-on  collars 
(1/4”  bore).  The  hollow  cylindrical  weights  slide  over  the  threaded  rods  and  are  held  in 
place  with  the  small  clamp-on  collars.  Six  100  gram  and  five  500  gram  hollow  weights 
are  available.  Hand  knobs  on  the  ends  of  the  threaded  rods  allow  the  user  to  make  slight 
adjustments  in  weight  position  by  turning  clockwise  or  counterclockwise. 

Individual  components  are  attached  to  their  respective  mounting  plates  using  a  vari¬ 
ety  of  structural  support  mechanisms.  The  momentum  wheels  are  attached  to  a  mounting 
plate  using  a  cantilevered  support  ‘shelf’  structure.  To  prevent  debris  (such  as  a  loose 
screw)  from  being  ejected  by  the  rotating  wheels,  the  momentum  wheels  are  enclosed  in 
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a  safety  housing.  This  housing  consists  of  a  five-sided  lexan  box  which  extends  outside  of 
the  truss  bay  in  the  z-direction.  One  side  of  the  box  is  attached  to  a  mounting  plate  (not 
the  momentum  wheel  mounting  plate)  and  the  other  side  is  free.  The  sixth  side  of  the 
box  consists  of  a  lexan  sheet  mounted  to  the  same  plate  as  the  momentum  wheels.  Dur¬ 
ing  SIMSAT  assembly,  the  five-sided  lexan  box  ’slides’  over  the  momentum  wheels  until 
a  solid  press  fit  is  achieved;  the  final  configuration  is  similar  to  that  of  a  cake  box  used 
to  transport  baked  goods  without  damage.  All  lexan  sheets  used  to  construct  the  box  are 
0.220”  thick.  Clearance  between  the  momentum  wheels  and  the  interior  of  the  lexan  box  is 
approximately  0.5”  to  1.0”.  The  cake  box  configuration  allows  the  user  to  remove  only  the 
exterior  mounting  plates  for  access  to  momentum  wheels  and  motors  during  maintenance. 

Each  battery  is  attached  to  its  respective  mounting  plate  using  an  aluminum  housing 
which  partially  encloses  the  battery  on  all  six  sides.  Two  nylon-tipped  bolts  are  mounted 
through  the  backplate;  these  bolts  can  be  tightened  to  press  upon  the  battery  contact  plate 
(held  on  the  battery  with  adhesive)  to  ensure  a  snug  fit.  The  removable  backplate  allows 
for  easy  access  and  replacement  of  the  battery  between  experiments.  The  battery  housing 
does  not  enclose  the  terminal  leads  so  quick-disconnect  wiring  connections  can  be  made  to 
the  batteries.  The  battery  housing  is  attached  to  the  mounting  plate  via  four  bolts. 

The  AutoBox  is  attached  to  its  respective  mounting  plate  using  a  combination  of  bl¬ 
and  L-brackets.  Polyurethane  padding  is  inserted  between  the  brackets  and  the  Autobox 
to  provide  adequate  vibration  isolation  for  electronic  components. 

An  aluminum  gyroscope  housing  provides  a  support  and  mounting  structure  for  the 
Humphrey  gyro.  The  RadioLAN  transceiver  is  attached  directly  to  the  mounting  plate 
using  integral  screw  attachments. 

K.3  Structure  Summary 

Overall,  the  SIMSAT  structural  design  emphasizes  modularity  and  ease  of  reconfig¬ 
uration,  while  attempting  to  minimize  structural  mass  and  complexity. 
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1  Layout  (support 


Aluminum  787&-T7  Collar 
4,875*  00 


Figure  K.3  Truss  Attachment  Collar  -  Front  View 


Aluminum  ?G75-T7  Colters 


Figure  K.4  Truss  Attachment  Collars  -  Side  View 


Payload/Dummy  Mass  Mounting  Hate 
-Aluminum  plate  is  1/4”  thick 

-4  large  holes  should  allow  1"  OD  stainless  steel  rods  to  pass  through 

-212  small  holes  should  be  threaded  to  fit  a  5/16"  bolt,  small  hole  centers  are  1"  apart 

horizontally  and  vertically 

-All  dimensions  shown  are  in  inches 


Payload  Mounting  Plate 
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Figure  K.5 


ire  K.7 


>lid  Form  View 


Aluminum  Plate  Template 

-4  large  holes  should  allow  ln  outer  diameter  Stainless  Steel-316 
tubes  (with  0.065"  wall  thickness)  to  pass  through 
-4  small  holes  are  for  L-bracket  attachment  for  cross-members 
-All  dimensions  shown  are  in  inches 


Comers  on  all  plates 


Figure  K.9  Standard  Mounting  Plate  Template 
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Two  Battery  Mounting  Plate  Template 


1/4"  diameter  holes  are  not  threaded 
These  holes  interface  with  l/4"-20  screws 
that  protrude  from  base  of  battery 

hmigtngH 


T i 


Figure  K.10  Two-Battery  Mounting  Plate  Template 
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Battery  Housing-Side  View 


Back 

Plate 


BATIERYMTaideviewHOLESOUT.dwg 


Figure  K.13  Battery  Housing  -  Side  View 
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Battery  Housing  Pieces 
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Figure  K.14  Battery  Housing  Pieces 


Find  big  hole  diameter  of  steel  plates  that  gives  a  particular  mass 
dimensions  in  cm 


w  :=  35 
1  :=53 

t  :=  0. 15875  (using  1/16"  thick  plate) 

rsmall  :=  1.27  (using  four  1  inch  diameter  holes  for  stainless  steel  rods) 

rtiny  :=  0.2413  (using  four  0.1 9  inch  diameter  holes  for  1 0-32  screws  for  stiffening 

member  L-bracket) 

5steel  :=7.85g/cm3 

Initial  Guess 
rbig  :=5 


Given 

2000»8steel-[w-l*t-  (rbig2-7t-t)  -  4- (rsmall2 -7C-t)  -  4^(rtiny2’7C-t)] 


x  :=Find(rbig) 

x  =  8.539696350203382  2  kg  steel  plate  hole  radius  in  cm 


2.54, 


•2  =  6.72417 


2  kg  steel  1/1 6”  plate  hole  DIAMETER  =6.724 17  inches 


w  :=  35 
1  :=  53 

t  :=  0.47625  (using  3/16"  thick  plate) 

rsmall  :=  1.27  (using  1  inch  diameter  holes  for  stainless  steel  rods) 

rtiny  :=  0.2413  (using  four  0.19  inch  diameter  holes  for  1 0-32  screws  for  stiffening 

member  L-bracket) 

8steel  :=7.85g/cm3 

Initial  Guess 
rbig  !=  1 

cwplatethickness4.mcd 


1 


Figure  K.15  MathCad7  Counterweight  Mass  Calculations  (page  1  of  5) 
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Given 


5000=6steel{w-l-t-  (rbig2*7C -t)  -  4-(rsmall2-7C-t)  -  4-(rtiny2-K-t)] 
x:=Find(rbig) 

x=  12.57253889023823  5  kg  steel  plate  hole  radius  in  cm 

•2  =  9.89964  6  k$  steel  3/16*  plate  hole  DIAMETER^  9.33964  inches 


t  :=  .635  (using  1/4"  thick  STEEL  plate) 

5steel  :=7.85  g/cm3 

Initial  Guess 
rbig  :=10 

Given 

5000=8steel-[w-l-t-  (rbig2*7C  -t)  -  4-(rsmall2-JC-t)  -  4-(rtiny2-7C-t)] 

y  :=Find(rbig) 

y«  1 6. 263352503 02494 

j_L.J  -2  =  12.80579  5  kg  steel  1/4“  plate  hole  DIAMETER  «  12.80579  inches 
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Find  dimensions  for  Carbon  Steel  1018  rectangles  that  attach  as  weight  to  payload  plate 

h:=5.08  cm  (2”) 
w:=  10.16  cm  (4") 

5  steellOlS  :=7*87  9/cm3 

j (5000) 

5  steell018*h  w 

1  =  12.30943  cm  length  inches  ^ 

le°gth  inches  =  4846 

5  kg  steel  block  dimensions  *  T  x  4“  x  4.846* 


h  :=5.08  cm  (2") 
w:=  10.16  cm  (4") 

8  steell018  :=7'87  9/crr|3 

1  (1000) 

8  steell018'h  w 

1=2.46189  cm  len8th  inches ;=^ 

lenSth  inches  =  0969 

(j  kg  steel  Sock  dimensions  «  2“  x  4"  x  Q  J969" 
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Find  dimensions  for  hollow  steel  cylinders  for  counterweight  mechanism  rods: 

8  steel 1=7  85  9/cm3 

rhole  :=-3175  cm  (hole  fits  1/4"  diameter  threaded  rods) 
r  outer  :=  1  -5875cm  0  -25"  outer  diameter  steel  cylinder) 

Initial  Guess 
length  :=  1 

Given 

100«5steel^r  0Uter2,7t’IenSth  "  r  hole2,71  '!etlSth) 

x  :=Find(  length) 
x  =  1.67603  cm 

i  —|  =  0.65985  1 0Q  gram  steel  weight  cylinder  length  *  0.65985  inches 

\  2.54/  . J . : •*" . .  '  " ' * 


8  steel :=7  85  9/cm3 

r  hole :=*3 175  cm  (hole  fits  1/4”  diameter  threaded  rods) 
r  outer  :=1-5875cm  t1  -25"  outer  diameter  steel  cylinder) 

Initial  Guess 
length  :=  1 


Given 

500*8steel  •  (r  QUter2  -7C  -length  -  r  hole2 -ic  -length) 

x  :=Find(  length) 
x=  8.38015  cm 

=  3.29927  500  gram  steel  weight  cylinder  length  *  3.29927  Indies. 
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For  counterweight,  Simsat  needs: 

--four  2  kg  steel  plates 
--four  5  kg  steel  plates 

-four  1  kg  carbon  steel-101 8  blocks  2"  x  4"  x  0.969"  with  5/1 6H  holes 
-four  5  kg  carbon  steel-101 8  blocks  2"  x  4"  x  4.846"  with  5/1 6"  holes 
-four  1  kg  carbon  steel- 101 8  blocks  2"  x  4"  x  0.969"  with  1/4"  holes 
-one  5  kg  carbon  steel-1018  block  2"  x  4"  x  4.846"  with  1/4"  holes 
-six  100  gram  steel  hollow  cylinders  1 .25"  OD,  0.25"  diameter  hole,  0.65985" 
long 

-five  500  gram  steel  hollow  cylinders  1 .25"  OD,  0.25"  diameter  hole,  3.299"  long 
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Counter-Weight  Mechanism  Pegboard 
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Figure  K.16  Counterweight  Fine-Tuning  Mechanism  with  Weights 


Payload  Mounting  Plate 
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Figure  K.17  Payload  Plate  with  Weights 


Figure  K.19  Counterweight  Fine-Tuning  Balance  Mechanism  -  Perspective  View 
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Counter-Weight  Mechanism— Pegboard  Design 


Comcre  are  slightly 
rounded  to  eliminate  sharp 
points 


Mass  (approx)  -  2.93  lbs 


. .  irmrinn — i —  in 


Figure  K.20  Counterweight  Fine-Tuning  Mechanism  -  Pegboard  Design 
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Counter-Weight  Mechanism— Right  Side  View 

*  indicates  l/4"-20  Threaded 


Figure  K.21  Counterweight  Mechanism  with  Dimensions  -  Right  Side  View 

K-29 


Counter-Weight  Mecfcinjbra-Froiit  View 


Figure  K.22  Counterweight  Mechanism  with  Dimensions  (Pegboard  Not  Shown) 
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FRONT  VIEW-Momentum  Wheel  Bay 
Subsystem  centered  between  stainless  steel  rods  along  "y"  axis 

Mounting  Mounting 

Plate  1  Plate  2 


Coordinate  origin  is  located  on  surface  of 
mounting  plate  1  (back  right  edge). 


Center  of  mass  of 

momentum  wbeel/motor/shelf/Lexan  box 
subsystem  is  located  at: 
x=  13.074  cm  =  5.147" 
y= 27.842  cm  =  10.961" 
z- 17.500  cm -6.89" 


Clearance  between  spinning  momentum  wheels 
and  inside  of  Lexan  box  is  approximately  1/2"  to  1" 


r^r: 

2.433"  J  2.622"  -> 

RIGHT  SIDE  VIEW 


Figure  K.23  Momentum  Wheel  Bay  (Amplifiers  Not  Shown) 
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LEXAN  SAFETY  BOX-Front  View 


Mounting 

Plate  1 

\ 


Top  side:  - 


All  lengths  are  defined  in  the 
direction  of  the  x,  y  and  z  axes. 


y 

i 


Mounting 
Plate  2 


ren  side  or  nox  is 
mounting  plate  1: 
x  -  0.220" 
y=  16" 


y=  0220" 
z= 19.291" 


A  —  1U.TJU 

1  y=  0220" 

N._ 

z=  19291"  i 

T  - - 

' 

Front*  Back  sides:  If 

x  =  10.236" 

y- 15.1806" 

z= 0.220" 

\  ^Bottom  side: 

u  \  x  = 

10.456"  " 

Five-sided  Lexan  box  is 
attached  to  mounting  plate  2 


''Right  side: 
x- 0.220" 
y= 15.1806" 
z- 19291" 


LEXAMSAPBITBOaanKALAl( 


Figure  K.24  Lexan  Box  (Momentum  Wheels  and  Motors  Not  Shown) 
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Gyro  Housing-Top  View 


Removable  U-Clamp  is  attached  to  plate  (and  to  top  of 
gyro)  by  appropriate  means  with  no  (or  slight)  protrusion 
out  bottom  of  plate 


gyrobraamgwC<2AMPwta^ 


Figure  K.26  Gyroscope  Housing  for  Attachment  to  Mounting  Plate  -  Front  View 
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Gyro  Housing-Side  View 


gyrohouflingwC-CIAMPwtcxt&dimSIDEVIEW.dwg 


Figure  K.27  Gyroscope  Housing  -  Side  View 
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Figure  K.28  Gyro,  Battery,  and  Transceiver  Mounting 
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AUTOBOX  U-CLAMP  &,  FOUR  L-BRACKETS 


Aluminum 
0.090"  Aide 


Front  View 


i" 


1 S' 

_ L 

—  is*  ■ 

U 

15" 


-17 


Top  View 


U-clamp  provides  1/2"  clearance  around  AutoBox 

UBRAXXFnBRArXMbrAUTOeOX^wf 


Figure  K.29  AutoBox  U-clamp  and  Restraint  L-brackets 
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Steel  "Anti-Tipping”  Collar  for  Air  Bearing  Stanchions 

Side  View 


ANTITIPSTRIP.dwg 


Figure  K.31  Stanchion  Restraint  Collars  -  Side  View 
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Steel  "Anti-Tipping"  Collar  for  Air  Bearing  Stanchions 
Top  View 


Holes  are  not  threaded,  but  they 
should  fit  a  3/8"-16  bolt  Holes  are 


Air  Bearing  Stanchion  Holes  (not  shown)  should  be  threaded  to  accept  a 
3/8M6  boh  with  at  least  3/4"  penetration. 


AhnTITPSTRIPtDpvkwdwg 


Figure  K.32  Stanchion  Restraint  Collars  -  Top  View 
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Appendix  L.  Finite- Element  Modeling 

L.l  Overview 

The  inputs  for  each  finite-element  model  are  listed  in  this  appendix  in  MKS  units. 
Inputs  include  the  nodal  coordinates,  loads,  material  properties,  and  element  masses  and 
inertias.  Moreover,  the  static  deflections  are  listed,  with  deflections  designated  for  each 
node  as  computed  by  the  CADRE  software. 

L.2  CADRE  Models 

The  payload-side  model  included  the  AutoBox,  rate  gyros,  battery,  communications 
equipment,  an  18kg  dummy  payload,  and  structures.  This  model  is  shown  in  Figure  L.l. 
The  momentum  wheel-side  model  included  the  momentum  wheel  assembly  (to  include  three 
momentum  wheels  with  motors,  shelving  structure,  and  lexan  enclosure),  two  batteries, 
three  motor  amps,  and  structures.  The  inputs  and  displacement  results  of  the  CADRE 
models  are  listed  at  the  end  of  this  appendix. 

L.3  CADRE  Pro  Model 

The  momentum  wheel-side  structure  was  also  modeled  using  the  CADRE  Pro  soft¬ 
ware.  This  model  allowed  the  construction  and  analysis  of  2-D  plates,  also  shown  in 
Figure  L.l.  The  same  nodal  loading  parameters  were  used  in  the  CADRE  Pro  model  as 
in  the  CADRE  model,  with  updated  material  specifications. 
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(b)  Wheel-Side  CADRE  Pro  Model 


Figure  L.l 


Finite-Element  Models 
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Table  L.l  Payload-Side  Nodal  Coordinates 


Basic  Data: 


Structural  Nodes 

49 

Reference 

Nodes 

2 

Number 

of 

elements 

66 

Properties  per  Element 

4 

Number 

of 

bounds 

49 

Number 

of  Mass  Nodes 

49 

Nodal  Coordinates: 

I  dent 

X 

Y 

Z 

0 

0000.0000 

0000.0000 

0000.0000 

1 

0000.0700 

0000.0000 

0000.0000 

2 

0000.1400 

0000.0000 

0000.0000 

3 

0000.2000 

0000.0000 

0000.0000 

4 

0000.2600 

0000.0000 

0000..0000 

5 

0000.3200 

0000.0000 

0000.0000 

6 

0000.3800 

0000.0000 

0000.0000 

7 

0000.4400 

0000.0000 

0000.0000 

8 

0000.5200 

0000.0000 

0000.0000 

9 

0000.6000 

0000.0000 

0000.0000 

10 

0000.0000 

0000.0000 

-0000.2400 

11 

0000.0700 

0000.0000 

-0000.2400 

12 

0000.1400 

0000.0000 

-0000.2400 

13 

0000.2000 

0000.0000 

-0000.2400 

14 

0000.2600 

0000.0000 

-0000.2400 

15 

0000.3200 

0000.0000 

-0000.2400 

16 

0000.3800 

0000.0000 

-0000.2400 

17 

0000.4400 

0000.0000 

-0000.2400 

18 

0000.5200 

0000.0000 

-0000.2400 

19 

0000.6000 

0000.0000 

-0000.2400 

20 

0000.0000 

0000.4400 

0000.0000 

21 

0000.0700 

0000.4400 

0000.0000 

22 

0000.1400 

0000.4400 

0000.0000 

23 

0000.2000 

0000.4400 

0000.0000 

24 

0000.2600 

0000.4400 

0000.0000 

25 

0000.3200 

0000.4400 

0000.0000 

26 

0000.3800 

0000.4400 

0000.0000 

27 

0000.4400 

0000.4400 

0000.0000 

28 

0000.5200 

0000.4400 

0000.0000 

29 

0000.6000 

0000.4400 

0000.0000 

30 

0000.0000 

0000.4400 

-0000.2400 

31 

0000.0700 

0000.4400 

-0000.2400 

32 

0000.1400 

0000.4400 

-0000.2400 

33 

0000.2000 

0000.4400 

-0000.2400 

34 

0000.2600 

0000.4400 

-0000.2400 

35 

0000.3200 

0000.4400 

-0000.2400 

36 

0000.3800 

0000.4400 

-0000.2400 

37 

0000.4400 

0000.4400 

-0000.2400 

38 

0000.5200 

0000.4400 

-0000.2400 

39 

0000.6000 

0000.4400 

-0000.2400 

40 

0000.1400 

0000.2200 

0000.0000 

41 

0000.1400 

0000.2200 

-0000.1200 

42 

0000.1400 

0000.2200 

-0000.2400 

43 

0000.2000 

0000.2200 

0000.0000 

44 

0000.2000 

0000.2200 

-0000.1200 

45 

0000.2000 

0000.2200 

-0000.2400 

46 

0000.4400 

0000.2200 

0000.0000 

47 

0000.4400 

0000.2200 

-0000.1200 

48 

0000.4400 

0000.2200 

-0000.2400 

49 

0000.0000 

0000.2200 

0000.0000 

50 

0000.0000 

0000.2200 

-0000.2400 
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Table  L.2  Payload-Side  Element  Specifications 


Element  Definition  Data:  (Properties) 


I dent  Type 

AE 

Ely 

EIz 

JG 

0000.0001 

S 

2.253E+07 

1 . 751E+03 

1.751E+03 

1. 301E+03 

0001.0002 

S 

2.253E+07 

1 . 751E+03 

1 . 751E+03 

1 . 301E+03 

0002.0003 

S 

2.253E+07 

1 . 751E+03 

1 . 751E+03 

1 . 301E+03 

0003.0004 

S 

2 . 253E+07 

1 . 751E+03 

1.751E+03 

1 . 301E4-03 

0004.0005 

S 

2.253E+07 

1.751E+03 

1.751E+03 

1 . 301E+03 

0005.0006 

S 

2.253E+07 

1.751E+03 

1.751E+03 

1 . 301E+03 

0006.0007 

S 

2.253E+07 

1.751E+03 

1.751E+03 

1 . 301E+03 

0007.0008 

s 

2 . 253E+07 

1.751E+03 

1 . 751E+03 

1 . 301E+03 

0008.0009 

s 

2.253E+07 

1.751E+03 

1.751E+03 

1 . 301E+03 

0010.0011 

s 

2.253E+07 

1.751E+03 

1.751E+03 

1 . 301E+03 

0011.0012 

s 

2.253E+07 

1 . 751E+03 

1 . 751E+03 

1 . 301E+03 

0012.0013 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1.301E+03 

0013.0014 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1 . 301E+03 

0014.0015 

s 

2.253E+07 

1.751E+03 

1.751E+03 

1 . 301E+03 

0015.0016 

s 

2.253E+07 

1 . 751E+03 

1 . 751E+03 

1 . 301E+03 

0016.0017 

s 

2.253E+07 

1 . 751E+03 

1 . 751E+03 

1 . 301E+03 

0017.0018 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1. 301E+03 

0018.0019 

s 

2.253E+07 

1.751E+03 

1.751E+03 

1 . 301E+03 

0020.0021 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1. 301E+03 

0021.0022 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1 . 301E+03 

0022.0023 

s 

2.253E+07 

1 . 751E+03 

1 . 751E+03 

1 . 301E+03 

0023.0024 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1 . 301E+03 

0024.0025 

s 

2.253E+07 

1 . 751E4-03 

1.751E+03 

1 . 301E+03 

0025.0026 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1. 301E+03 

0026.0027 

s 

2.253E+07 

1.751E+03 

1 . 751E+03 

1 . 301E+03 

0027.0028 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1. 301E+03 

0028.0029 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1. 301E+03 

0030.0031 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1. 301E+03 

0031.0032 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1 . 301E+03 

0032.0033 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1.301E+03 

0033.0034 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1 . 301E+03 

0034.0035 

s 

2.253E+07 

1 . 751E+03 

1 . 751E+03 

1 . 301E+03 

0035.0036 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1. 301E+03 

0036.0037 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1.301E+03 

0037.0038 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1.301E+03 

0038.0039 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1. 301E+03 

0002.0012 

s 

1.374E+06 

2 . 148E+00 

2.148E+00 

1.615E+00 

0003.0013 

s 

1 . 374E+06 

2 . 148E+00 

2 . 148E+00 

1 . 615E+00 

0007.0017 

s 

1 . 374E+06 

2 . 148E+00 

2.148E+00 

1 . 615E+00 

0002.0040 

s 

1 . 374E+06 

2.148E+00 

2 .148E+00 

1. 615E+00 

0003.0043 

s 

1.374E+06 

2 . 148E+00 

2.148E+00 

1.615E+00 

0007.0046 

s 

1 . 374E+06 

2 . 14  8E+00 

2.148E+00 

1. 615E+00 

0022.0032 

s 

1.374E+06 

2 . 148E+00 

2 . 148E+00 

1. 615E+00 

0023.0033 

s 

1.374E+06 

2 . 148E+0Q 

2 . 148E+00 

1 . 615E+00 

0027.0037 

s 

1.374E+06 

2 . 14  8E 4-00 

2.148E+00 

1.615E+00 

0040.0022 

s 

1.374E+06 

2.148E+00 

2 . 148E+00 

1 . 615E+00 

0043.0023 

s 

1.374E+06 

2 . 148E+00 

2.148E+00 

1 .615E+00 

0046.0027 

s 

1.374E+06 

2 . 148E+00 

2 . 148E+00 

1.615E+00 

0032.0042 

s 

1 . 374E+06 

2 . 148E+00 

2 . 148E+00 

1. 615E+00 

0042.0012 

s 

1.374E+06 

2 . 148E+00 

2 . 148E+00 

1. 615E+00 

0033.0045 

s 

1.374E+06 

2 . 148E+00 

2 . 148E+00 

1 . 615E+00 

0045.0013 

s 

1 . 374E+06 

2 . 148E+00 

2 . 148E+00 

1. 615E+00 

0037.0048 

s 

1 . 374E+06 

2 . 148E+00 

2 . 148E+00 

1 . 615E+00 

0048.0017 

s 

1.374E+06 

2 . 148E+00 

2 . 148E+00 

1.615E+00 

0002.0041 

s 

1.374E+06 

2.148E+00 

2.148E+00 

1 . 615E+00 

0012.0041 

s 

1 . 374E+06 

2 . 148E+00 

2.148E+00 

1. 615E+00 

0022.0041 

s 

1 . 374E+06 

2 . 148E+00 

2 . 148E+00 

1. 615E+00 

0032.0041 

s 

1 . 374E+06 

2.148E+00 

2.148E+00 

1 . 615E+00 

0003.0044 

s 

1 . 374E+06 

2 . 148E+00 

2 . 148E+00 

1.615E+00 

0013.0044 

s 

1.374E+06 

2 . 148E+00 

2 . 148E+00 

1. 615E+00 

0023.0044 

s 

1.374E+06 

2 . 148E+00 

2.148E+00 

1 . 615E+00 

0033.0044 

s 

1.374E+06 

2.148E+00 

2.148E+00 

1. 615E+00 

0007.0047 

s 

1 . 374E+06 

2 . 148E+00 

2 . 148E+00 

1. 615E+00 

0017.0047 

s 

1.374E+06 

2 . 148E+00 

2.148E+00 

1. 615E+00 

0027.0047 

s 

1.374E+06 

2 . 148E+00 

2.148E+00 

1.615E+00 

0037.0047 

s 

1 . 374E+06 

2 . 148E+00 

2 . 148E+00 

1 . 615E+00 
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Table  L.3  Payload-Side  Nodal  Mass  Properties 


Mass  Properties: 


Node 

Mass 

lx 

iy 

Iz 

Xcg 

Ycg 

2  eg 

DOF 

0 

1 . OOOE-Ol 

0 . OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

010000 

1 

1 . 000E-01 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

7.000E-02 

O.OOOE+OO 

O.OOOE+OO 

010000 

2 

4 . 500E-01 

0. OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

1 . 400E-01 

O.OOOE+OO 

O.OOOE+OO 

010000 

3 

4 . 500E-01 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

2. OOOE-Ol 

O.OOOE+OO 

O.OOOE+OO 

010000 

4 

1. OOOE-Ol 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

2.600E-01  ’ 

O.OOOE+OO 

O.OOOE+OO 

010000 

5 

1- 000E-01 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

3.200E-01 

O.OOOE+OO 

O.OOOE+OO 

010000 

6 

1. OOOE-Ol 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

3.800E-01 

O.OOOE+OO 

O.OOOE+OO 

010000 

7 

4 . 500E-01 

O.OOOE+OO 

O.OOOE+OO 

0 . OOOE+OO 

4 . 400E-01 

O.OOOE+OO 

O.OOOE+OO 

010000 

8 

1. 000E-01 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

5 . 200E-01 

0 . OOOE+OO 

O.OOOE+OO 

010000 

9 

1- OOOE-Ol 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

6. OOOE-Ol 

O.OOOE+OO 

O.OOOE+OO 

010000 

10 

1. OOOE-Ol 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

-2.400E-01 

010000 

11 

1. OOOE-Ol 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

7 . 000E-02 

O.OOOE+OO 

—2 . 400E-01 

010000 

12 

4 . 500E-01 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

1 . 400E-01 

O.OOOE+OO 

-2.400E-01 

010000 

13 

4  - 500E-01 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

2. OOOE-Ol 

O.OOOE+OO 

—2 . 400E-01 

010000 

14 

1. OOOE-Ol 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

2. 600E-01 

O.OOOE+OO 

—2 . 400E-01 

010000 

15 

1. OOOE-Ol 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

3 . 200E-01 

O.OOOE+OO 

—2 . 400E-01 

010000 

16 

1. OOOE-Ol 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

3 . 800E-01 

O.OOOE+OO 

—2 . 400E-01 

010000 

17 

4 . 500E-01 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

4 . 400E-01 

O.OOOE+OO 

—2 . 400E-01 

010000 

18 

1. OOOE-Ol 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

5 . 200E-01 

O.OOOE+OO 

-2 . 400E-01 

010000 

19 

1. OOOE-Ol 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

6. OOOE-Ol 

O.OOOE+OO 

-2 . 400E-01 

010000 

20 

1. OOOE-Ol 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

4 . 400E-01 

O.OOOE+OO 

010000 

21 

1. OOOE-Ol 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

7 . 000E-02 

4.400E-01 

O.OOOE+OO 

010000 

22 

4 . 500E-01 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

1 . 400E-01 

4 . 400E-01 

O.OOOE+OO 

010000 

23 

4 . 500E-01 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

2. OOOE-Ol 

4 . 400E-01 

O.OOOE+OO 

010000 

24 

1. OOOE-Ol 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

2 . 600E-01 

4 . 400E-01 

O.OOOE+OO 

010000 

25 

1. OOOE-Ol 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

3.200E-01 

4 . 400E-01 

O.OOOE+OO 

010000 

26 

1. OOOE-Ol 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

3 . 800E-01 

4 . 400E-01 

O.OOOE+OO 

010000 

27 

4 . 500E-01 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

4 . 400E-01 

4 . 400E-01 

O.OOOE+OO 

010000 

28 

1. OOOE-Ol 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

5 . 200E-01 

4 . 400E-01 

O.OOOE+OO 

010000 

29 

1. OOOE-Ol 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

6. OOOE-Ol 

4 . 400E-01 

O.OOOE+OO 

010000 

30 

1. OOOE-Ol 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

4.400E-01 

-2.400E-01 

010000 

31 

1. OOOE-Ol 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

7 . 000E-02 

4 . 400E-01 

-2.400E-01 

010000 

32 

4 . 500E-01 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

1 . 400E-01 

4 . 400E-01 

-2.400E-01 

010000 

33 

4.500E-01 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

2. OOOE-Ol 

4 . 400E-01 

-2.400E-01 

010000 

34 

1. OOOE-Ol 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

2 . 600E-01 

4 . 400E-01 

—2 . 400E-01 

010000 

35 

1. OOOE-Ol 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

3 . 200E-01 

4 . 400E-01 

-2.400E-01 

010000 

36 

1. OOOE-Ol 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

3 . 800E-01 

4 . 400E-01 

-2.400E-01 

010000 

37 

4.500E-01 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

4 . 400E-01 

4 . 400E-01 

-2.400E-01 

010000 

38 

1. OOOE-Ol 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

5 . 200E-01 

4 . 400E-01 

—2 . 400E-01 

010000 

39 

1. OOOE-Ol 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

6. OOOE-Ol 

4 . 400E-01 

-2.400E-01 

010000 

40 

3.500E-01 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

1 . 400E-01 

2.200E-01 

O.OOOE+OO 

010000 

42 

3.500E-01 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

1 . 400E-01 

2.200E-01 

-2.400E-01 

010000 

41 

1.200E+01 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

1. OOOE-Ol 

2 . 200E-01 

—1 . 200E-01 

010000 

43 

3. 500E-01 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

2. OOOE-Ol 

2 . 200E-01 

O.OOOE+OO 

010000 

45 

3.500E-01 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

2. OOOE-Ol 

2 . 200E-01 

-2.400E-01 

010000 

44 

1.000E+01 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

3 . 100E-01 

2.200E-01 

-1.200E-01 

010000 

46 

3.500E-01 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

4 . 400E-01 

2.200E-01 

O.OOOE+OO 

010000 

48 

3.500E-01 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

4 . 400E-01 

2.200E-01 

—2 . 400E-01 

010000 

47 

1 . 800E+01 

O.OOOE+OO 

O.OOOE+OO 

O.OOOE+OO 

5 . 600E-01 

2.200E-01 

-1.200E-01 

010000 
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Table  L.4  Payload-Side  Displacements 


Node 

000.000 

001.000 

002.000 

003.000 

004.000 

005.000 

006.000 

007.000 

008.000 

009.000 

010.000 

011.000 

012.000 

013.000 

014.000 

015.000 

016.000 

017.000 

018.000 

019.000 

020.000 

021.000 

022.000 

023.000 

024.000 

025.000 

026.000 

027.000 

028.000 

029.000 

030.000 

031.000 

032.000 

033.000 

034.000 

035.000 

036.000 

037.000 

038.000 

039.000 

040.000 

041.000 

042.000 

043.000 

044.000 

045.000 

046.000 

047.000 

048.000 


Nodal  Displacements: 


X 

Y 

Z 

Rx 

Ry 

Rz 

0 .OOOE+OO 

0. OOOE+OO 

0 .OOOE+OO 

0 . OOOE+OO 

0  .  OOOE+OO 

0 .OOOE+OO 

6 . 212E-09 

4 . 571E-05 

-3 . 595E-07 

2 . 051E-07 

8 . 649E-06 

1 . 248E-03 

1 . 242E-08 

1.666E-04 

—9 . 837E-07 

4 . 102E-07 

7.563E-0 6 

2 . 148E-03 

1.639E-08 

3 . 125E-04 

-1 . 334E-06 

5 . 387E-07 

4 . 677E-06 

2 . 685E-03 

1.866E-08 

4 . 860E-04 

-1 . 598E-06 

6.199E-07 

4 . 093E-06 

3 . 079E-03 

2 . 092E-08 

6 . 797E-04 

—1 . 824E-06 

7 . 010E-07 

3.412E-06 

3 . 359E-03 

2 . 319E-08 

8.868E-04 

-2 . 005E-06 

7 . 822E-07 

2 . 632E-06 

3 . 526E-03 

2 . 546E-08 

1 . 101E-03 

-2.138E-06 

8 . 634E-07 

1 . 754E-06 

3 . 582E-03 

2 . 546E-08 

1.388E-03 

-2 . 278E-06 

8 . 634E-07 

1.754E-06 

3 . 590E-03 

2 . 546E-08 

1 . 675E-Q3 

-2 . 418E-06 

8 . 634E-07 

1.754E-06 

3 . 592E-03 

0  .OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0  .OOOE+OO 

0.  OOOE+OO 

0 .OOOE+OO 

6 . 212E-09 

4 . 571E-05 

3 . 595E-07 

-2 . 051E-07 

-8 . 649E-06 

1.248E-03 

1 . 242E-08 

1 . 666E-04 

9 . 837E-07 

-4 . 102E-07 

-7.563E-06 

2 . 148E-03 

1 . 639E-08 

3 . 125E-04 

1 . 334E-06 

-5.387E-07 

-4 . 677E-06 

2 . 685E-03 

1 . 866E-08 

4 . 860E-04 

1 . 598E-06 

-6 . 199E-07 

-4.093E-06 

3.079E-03 

2 . 092E-08 

6 . 797E-04 

1 . 824E-0  6 

-7 . 010E-07 

-3 . 412E-06 

3.359E-03 

2 . 319E-08 

8.868E-04 

2 . Q05E-06 

-7.822E-07 

-2. 632E-06 

3 . 526E-G3 

2 . 546E-08 

1.101E-03 

2 . 138E-06 

—8 . 634E— 07 

-1.754E-06 

3 . 582E-03 

2 . 546E-08 

1 . 388E-03 

2.278E-06 

-8 . 634E-07 

—1 . 754E-06 

3 . 590E-03 

2 . 546E-08 

1 . 675E-03 

2.418E-06 

-8 . 634E-07 

-1 . 754E-06 

3 . 592E-03 

0  .OOOE+OO 

0 .OOOE+OO 

0 .OOOE+OO 

0 .OOOE+OO 

0.  OOOE+OO 

0. OOOE+OO 

-6 . 212E-09 

4 . 571E-05 

3 . 595E-07 

2.051E-07 

-8 . 649E-*06 

1 . 248E-03 

-1 . 242E-08 

1 . 666E-04 

9 . 837E-07 

4 . 102E-07 

—7 . 563E-06 

2 . 148E-03 

— 1 . 639E-08 

3.125E-04 

1 . 334E-06 

5.387E-07 

-4 . 677E-0  6 

2 . 685E-03 

— 1 . 866E-08 

4 . 860E-04 

1 . 598E-06 

6.199E-07 

-4 . 093E-0  6 

3.079E-03 

-2 . 092E-08 

6.797E-04 

1 . 824E-06 

7 . 010E-07 

-3.412E-06 

3 . 359E-03 

-2 . 319E-08 

8 . 868E-04 

2.005E-06 

7 . 822E-07 

—2 . 632E-06 

3 . 526E-03 

—2 . 546E-08 

1 . 101E-03 

2 . 138E-Q6 

8.634E-07 

-1.754E-06 

3 . 582E-03 

-2 . 546E-08 

1 . 388E-03 

2 . 278E-06 

8 . 634E-07 

-1.754E-06 

3.590E-03 

-2 . 546E-08 

1.675E-03 

2.418E-06 

8 . 634E-07 

—1 . 754E-06 

3 . 592E-03 

0  .OOOE+OO 

0. OOOE+OO 

0 .OOOE+OO 

0 .OOOE+OO 

0 .OOOE+OO 

0.  OOOE+OO 

—6 . 212E-09 

4 . 571E-05 

-3 . 595E-07 

-2 . 051E-07 

8 . 649E-06 

1 . 248E—03 

-1 .242E-08 

1.666E-04 

-9.837E-07 

-4 . 102E-07 

7.563E-06 

2 . 148E-03 

—1 . 639E-08 

3 . 125E-04 

“1 . 334E-06 

-5 . 387E-07 

4.677E-06 

2.685E-03 

-1 .866E-08 

4 . 860E-04 

-1 . 598E-06 

-6.199E-07 

4.093E-06 

3.079E-03 

—2 . 092E—08 

6 . 797E-04 

-1.824E-06 

-7 . 010E-Q7 

3.412E-06 

3 . 359E-03 

-2.319E-08 

8 . 868E-04 

-2 . 005E-06 

-7 . 822E-07 

2. 632E-06 

3 . 526E-03 

“2 . 546E-08 

1 . 1Q1E-03 

-2 . 138E-06 

-8.634E-07 

1 . 754E—06 

3 . 582E-03 

-2  . 546E-08 

1 . 388E-03 

-2 . 278E-06 

-8 . 634E—07 

1.754E-06 

3 . 590E-03 

-2 . 546E-08 

1 . 675E-03 

-2.418E-06 

-8 . 634E-07 

1 . 754E-06 

3 . 592E-03 

-5 . 765E-21 

1 . 669E-04 

2 . 226E-19 

6.502E-06 

-2 . 774E-18 

-1.074E-03 

4 .044E-20 

1 . 742E-04 

2 . 091E-19 

-1.787E-16 

-2 . 243E-19 

-9.060E-04 

-1 . 578E-22 

1 . 669E-04 

1 . 965E-19 

-6 . 502E-06 

-3.143E-18 

-1.074E-03 

4 . 479E-20 

3.128E-04 

3 . 993E-19 

8 . 829E-06 

-3.473E-18 

—1 . 342E-03 

—3 . 797E-22 

3.191E-04 

3 . 611E-19 

-3 . 545E-16 

—2 . 268E-19 

—1 . 131E-03 

—4 . 442E-20 

3 . 128E-Q4 

4 . 297E-19 

-8.829E-06 

-4 . 018E— 18 

-1.342E-03 

-*9 . 634E-20 

1 . 101E-03 

1 . 680E-18 

1.414E-05 

-4 . 718E-18 

—1 . 791E-03 

-2.492E-20 

1 . 112E-03 

1 . 684E-18 

-1.451E-15 

-2 . 816E-19 

-1 . 507E-03 

-1 .066E-20 

1 . 101E-03 

1.518E-18 

-1 . 414E-05 

-5.687E-18 

—1 . 791E-03 
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Table  L.5  Wheel-Side  Nodal  Coordinates 


Basic  Data: 

Structrual  Nodes  49 

Reference  Nodes  0 

Number  of  elements  66 

Properties  per  Element  4 

Number  of  bounds  49 

Number  of  Loaded  Nodes  49 

Nodal  Coordinates : 

Ident  X  Y  Z 


0 

0000.0000 

0000.0000 

0000.0000 

1 

0000.0700 

0000.0000 

0000.0000 

2 

0000.1400 

0000.0000 

0000.0000 

3 

0000.2200 

0000.0000 

0000.0000 

4 

0000.2800 

0000.0000 

0000.0000 

5 

0000.3400 

0000.0000 

0000.0000 

6 

0000.4000 

0000.0000 

0000.0000 

7 

0000.4600 

0000.0000 

0000.0000 

8 

0000.5200 

0000.0000 

0000.0000 

9 

0000.6000 

0000.0000 

0000.0000 

10 

0000.0000 

0000.0000 

-0000.2400 

11 

0000.0700 

0000.0000 

-0000.2400 

12 

0000.1400 

0000.0000 

-0000.2400 

13 

0000.2200 

0000.0000 

-0000.2400 

14 

0000.2800 

0000.0000 

-0000.2400 

15 

0000.3400 

0000.0000 

-0000.2400 

16 

0000.4000 

0000.0000 

-0000.2400 

17 

0000.4600 

0000.0000 

-0000.2400 

18 

0000.5200 

0000.0000 

-0000.2400 

19 

0000.6000 

0000.0000 

-0000.2400 

20 

0000.0000 

0000.4400 

0000.0000 

21 

0000.0700 

0000.4400 

0000.0000 

22 

0000.1400 

0000.4400 

0000.0000 

23 

0000.2200 

0000.4400 

0000.0000 

24 

0000.2800 

0000.4400 

0000.0000 

25 

0000.3400 

0000.4400 

0000.0000 

26 

0000.4000 

0000.4400 

0000.0000 

27 

0000.4600 

0000.4400 

0000.0000 

28 

0000.5200 

0000.4400 

0000.0000 

29 

0000.6000 

0000.4400 

0000.0000 

30 

0000.0000 

0000.4400 

-0000.2400 

31 

0000.0700 

0000.4400 

-0000.2400 

32 

0000.1400 

0000.4400 

-0000.2400 

33 

0000.2200 

0000.4400 

-0000.2400 

34 

0000.2800 

0000.4400 

-0000.2400 

35 

0000.3400 

0000.4400 

-0000.2400 

36 

0000.4000 

0000.4400 

-0000.2400 

37 

0000.4600 

0000.4400 

-0000.2400 

38 

0000.5200 

0000.4400 

-0000.2400 

39 

0000.6000 

0000.4400 

-0000.2400 

40 

0000.1400 

0000.2200 

0000.0000 

41 

0000.1400 

0000.2200 

-0000.1200 

42 

0000.1400 

0000.2200 

-0000.2400 

43 

0000.2200 

0000.2200 

0000.0000 

44 

0000.2200 

0000.2200 

-0000.1200 

45 

0000.2200 

0000.2200 

-0000.2400 

46 

0000.5200 

0000.2200 

0000.0000 

47 

0000.5200 

0000.2200 

-0000.1200 

48 

0000.5200 

0000.2200 

-0000.2400 
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Table  L.6  Wheel-Side  Element  Specifications 


Element  Definition  Data:  (Properties) 


I dent  Type 

AE 

Ely 

EIz 

JG 

0000.0001 

S 

2.253E+07 

1 . 751E+03 

1 . 751E+03 

1 . 301E+03 

0001.0002 

s 

2.253E+07 

1.751E+03 

1.751E+03 

1.301E+03 

0002.0003 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1.301E+03 

0003.0004 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1 . 301E+03 

0004.0005 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1. 301E+03 

0005.0006 

s 

2.253E+07 

1 . 751E+03 

1 . 751E+03 

1. 301E+03 

0006.0007 

s 

2.253E+07 

1 , 751E+03 

1.751E+03 

1.301E+03 

0007.0008 

s 

2.253E+07 

1 . 751E+03 

1 . 751E+03 

1. 301E+03 

0008.0009 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1 . 301E+03 

0010.0011 

s 

2 .253E+07 

1.751E+03 

1.751E+03 

1 . 301E+03 

0011.0012 

s 

2.253E+07 

1.751E+03 

1 . 751E+03 

1 . 301E+03 

0012.0013 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1 . 301E+03 

0013.0014 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1.301Et03 

0014.0015 

s 

2 . 253E+07 

1 . 751E+03 

1.751E+03 

1 . 301E+03 

0015.0016 

s 

2.253E+07 

1 . 751E+03 

1 . 751E+03 

1. 301E+03 

0016.0017 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1.301E+03 

0017.0018 

s 

2 .253E+07 

1 . 751E+03 

1.751E+03 

1. 301E+03 

0018.0019 

s 

2.253E+07 

1 . 751E+03 

1 . 751E+03 

1. 301E+03 

0020.0021 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1. 301E+03 

0021.0022 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1.301E+03 

0022.0023 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1. 301E+03 

0023.0024 

s 

2 . 253E+07 

1 . 751E+03 

1.751E+03 

1 . 301E+03 

0024.0025 

s 

2.253E+07 

1.751E+03 

1.751E+03 

1.301E+03 

0025.0026 

s 

2.253E+07 

1 . 751E+03 

1 . 751E+03 

1.301E+03 

0026.0027 

s 

2.253E+07 

1 . 751E+03 

1 , 751E+03 

1.301E+03 

0027.0028 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1.301E+03 

0028.0029 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1.301E+03 

0030.0031 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1. 301E+03 

0031.0032 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1. 301E+03 

0032.0033 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1. 301E+03 

0033.0034 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1. 301E+03 

0034.0035 

s 

2  .253E+07 

1 . 751E+03 

1 . 751E+03 

1. 301E+03 

0035.0036 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1. 301E+03 

0036.0037 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1. 301E+03 

0037.0038 

s 

2.253E+07 

1 . 751E+03 

1.751E+03 

1 . 301E+03 

0038.0039 

s 

2 . 253E+07 

1 . 751E+03 

1.751E+03 

1.301E+03 

0002.0012 

s 

1 . 374E+06 

2 . 148E4-00 

2 . 148E+00 

1 . 615E+00 

0003.0013 

s 

1 . 374E+06 

2 . 148E+00 

2.148E+00 

1. 615E+00 

0008.0018 

s 

1 . 374E+06 

2 . 148E+00 

2 . 148E+00 

1 . 615E+00 

0002.0040 

s 

1 . 374E4-06 

2 . 148E+00 

2.148E+00 

1 . 615E+00 

0003.0043 

s 

1 . 374E+06 

2 . 148E+00 

2.148E+00 

1 . 615E+00 

0008.0046 

s 

1.374E+06 

2 . 14 8E+00 

2 . 148E+00 

1. 615E+00 

0022.0032 

s 

1.374E+06 

2 . 148E+00 

2 . 148E+00 

1.615E+00 

0023.0033 

s 

1.374E+06 

2 . 148E+00 

2.148E+00 

1.615E+00 

0028.0038 

s 

1.374E+06 

2 . 148E+00 

2.148E+00 

1 . 615E+00 

0040.0022 

s 

1 .374E+06 

2 . 148E+00 

2 . 148E+00 

1.615E+00 

0043.0023 

s 

1 . 374E+06 

2 . 148E+00 

2 . 148E+00 

1 . 615E+00 

0046.0028 

s 

1 . 374E+06 

2 . 148E+00 

2.148E+00 

1.615E+00 

0032.0042 

s 

1 . 374E+06 

2.148E+00 

2 . 148E+00 

1 . 615E+00 

0042.0012 

s 

1 . 374E+06 

2 . 148E+00 

2 . 148E+-00 

1 . 615E+00 

0033.0045 

s 

1 . 374E+06 

2 . 148E+00 

2 . 148E+00 

1. 615E+00 

0045.0013 

s 

1 . 374E+06 

2 . 148E+00 

2.148E+00 

1. 615E+00 

0038.0048 

s 

1 . 374E+06 

2 . 148E+00 

2 . 148E+00 

1. 615E+00 

0048.0018 

s 

1 . 374E+06 

2.148E+00 

2.148E+00 

1. 615E+00 

0002.0041 

s 

1.374E+06 

2 . 148E+00 

2 . 148E+00 

1. 615E+00 

0012.0041 

s 

1.374E+06 

2 . 148E+00 

2 . 148E+00 

1 . 615E+00 

0022.0041 

s 

1 . 374E+06 

2 . 148E+00 

2 . 148E+00 

1 . 615E+00 

0032.0041 

s 

1.374E+06 

2 . 148E+00 

2.148E+00 

1.615E+00 

0003.0044 

s 

1 . 374E+06 

2 . 14  8E 4-00 

2.148E+00 

1.615E+00 

0013.0044 

s 

1.374E+06 

2 . 148E+00 

2 . 148E+00 

1.615E+00 

0023.0044 

s 

1 . 374E+06 

2 . 148E+00 

2 . 148E+00 

1 . 615E+00 

0033.0044 

s 

1.374E+06 

2 . 148E+00 

2.148E+00 

1. 615E+00 

0008.0047 

s 

1 . 374E+06 

2 . 14  8E+00 

2 . 148E+00 

1 . 615E+00 

0018.0047 

s 

1 . 374E+06 

2 . 148E+00 

2 . 148E+00 

1 . 615E+00 

0028.0047 

s 

1.374E+06 

2 . 148E+00 

2.148E4-00 

1. 615E+00 

0038.0047 

s 

1.374E+06 

2 . 148E+00 

2.148E+00 

1. 615E+00 
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Table  L.7  Wheel-Side  External  Loading 


External  Nodal  Loads : 


Node 

Fx 

Fy 

Fz 

Mx 

My 

Mz 

0 

0.000E+00 

1. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0 . OOOE+OO 

0 . OOOE+OO 

1 

0. OOOE+OO 

1. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0 . OOOE+OO 

0. OOOE+OO 

2 

0 . 00  0E 4-00 

4.500E+00 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

3 

0. OOOE+OO 

4 . 500E+00 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

4 

0. OOOE+OO 

1. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

5 

0. 000E+00 

1. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

6 

0. OOOE+OO 

1. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

7 

0. OOOE+OO 

1. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

8 

0. OOOE+OO 

4 . 500E+00 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

9 

0. OOOE+OO 

1. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0 . OOOE+OO 

0. OOOE+OO 

10 

0. OOOE+OO 

1. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0 . OOOE+OO 

11 

0. OOOE+OO 

1. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0: OOOE+OO 

0. OOOE+OO 

12 

0. OOOE+OO 

4 . 500E+00 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

13 

0. OOOE+OO 

4 . 500E+00 

0. OOOE+OO 

0. OOOE+OO 

0 .OOOE+OO 

0. OOOE+OO 

14 

0. OOOE+OO 

1. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

.  0. OOOE+OO 

0. OOOE+OO 

15 

0. OOOE+OO 

1. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0 . OOOE+OO 

0. OOOE+OO 

16 

0. OOOE+OO 

1. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

17 

0. OOOE+OO 

1. OOOE+OO 

0 .OOOE+OO 

0. OOOE+OO 

0 .OOOE+OO 

0. OOOE+OO 

18 

0. OOOE+OO 

4 . 500E+00 

0 .OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

19 

0. OOOE+OO 

1. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

20 

0. OOOE+OO 

1. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

21 

0. OOOE+OO 

1. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

22 

0. OOOE+OO 

4 . 500E+00 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

23 

0. OOOE+OO 

4 . 500E+00 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

24 

0. OOOE+OO 

1. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

25 

0. OOOE+OO 

1. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

26 

0. OOOE+OO 

1. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

27 

0. OOOE+OO 

1. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

28 

0. OOOE+OO 

4 . 500E+00 

0. OOOE+OO 

0. OOOE+OO 

0 . OOOE+OO 

0. OOOE+OO 

29 

0. OOOE+OO 

1. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

30 

0. OOOE+OO 

1. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

31 

0. OOOE+OO 

1. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

32 

0. OOOE+OO 

4 . 500E+00 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

33 

0. OOOE+OO 

4 . 500E+00 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

34 

0. OOOE+OO 

1. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

35 

0. OOOE+OO 

1. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

36 

0. OOOE+OO 

1. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

37 

0. OOOE+OO 

1. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

38 

0. OOOE+OO 

4 . 500E+00 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

39 

0. OOOE+OO 

1. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

40 

0. OOOE+OO 

3 . 500E+00 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0 . OOOE+OO 

42 

0. OOOE+OO 

3.500E+00 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0 . OOOE+OO 

41 

0. OOOE+OO 

1.200E+02 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

43 

0. OOOE+OO 

3 . 500E+00 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

45 

0. OOOE+OO 

3 . 500E+00 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

44 

0. OOOE+OO 

2.200E+02 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

46 

0. OOOE+OO 

3.500E+00 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

48 

0. OOOE+OO 

3 . 500E+00 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

47 

0. OOOE+OO 

4 . OOOE+Ol 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 

0. OOOE+OO 
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Table  L.8  Wheel- Side  Displacements 


Node 

000.000 

001.000 

002.000 

003.000 

004.000 

005.000 

006.000 

007.000 

008.000 

009.000 

010.000 

011.000 

012.000 

013.000 

014.000 

015.000 

016.000 

017.000 

018.000 

019.000 

020.000 

021.000 

022.000 

023.000 

024.000 

025.000 

026.000 

027.000 

028.000 

029.000 

030.000 

031.000 

032.000 

033.000 

034.000 

035.000 

036.000 

037.000 

038.000 

039.000 

040.000 

041.000 

042.000 

043.000 

044.000 

045.000 

046.000 

047.000 

048.000 


Nodal  Displacements: 


X 

0.000E+00 
6 . 212E-09 
1 . 242E-08 
1 . 639E-08 
1 . 866E-08 
2 . 092E-08 
2 . 319E-08 
2 . 546E-08 
2.546E-08 
2.546E-08 
0 .000E+00 
6.212E-09 
1 .242E-08 
1 . 639E-08 
1 . 866E-08 
2.092E-08 
2.319E-08 
2.546E-08 
2 . 546E-08 
2 . 546E-08 
0 .000E+00 
—6 . 212E-G9 
-1 . 242E—08 
-1 . 639E-08 
-1 .866E-08 
-2.092E-08 
-2.319E-08 
-2 . 546E-08 
-2.546E-08 
-2.546E-08 
0 .000E+00 
—6 . 212E-09 
-1.242E-08 
“1 . 639E-08 
-1.866E-08 
-2 . 092E-08 
-2 . 319E-08 
-2 . 546E-08 
-2 . 546E-08 
-2 . 546E-08 
-5.765E-21 
4 . 044E-20 
-1.578E-22 
4 . 479E-20 
-3 . 797E-22 
-4 . 442E-20 
~9 . 634E-20 
-2 . 492E-20 
-1.066E-20 


Y 

0 .000E+00 
4.571E-05 
1 . 666E-04 
3.125E-04 
4.860E-04 
6.797E-04 
8.868E-04 
1 . 101E-03 
1.388E-03 
1 . 675E-03 
0.000E+00 
4.571E-05 
1. 666E-04 
3 . 125E-04 
4 . 860E-04 
6.797E-04 
8 . 868E-04 
1 . 101E-03 
1.388E-03 
1 . 675E-03 
O.OOOE+OO 
4 . 571E-05 
1 . 666E-04 
3 . 125E-04 
4 . 860E-04 
6 . 797E-04 
8 . 868E-04 
1 . 101E-03 
1.388E-03 
1.675E-03 
0.000E+00 
4 . 571E-05 
1 . 666E-04 
3 . 125E-04 
4 . 860E-04 
6.797E-04 
8 . 868E-04 
1 . 101E-03 
1.388E-03 
1 . 675E-03 
1 . 669E-04 
1 . 742E-04 
1. 669E-04 
3 . 128E-04 
3 . 191E-04 
3 . 128E-04 
1 . 101E-03 
1 . 112E-03 
1.101E-03 


Z 

0.000E+00 
—3 . 595E-07 
—9 . 837E-07 
—1 . 334E-06 
—1 . 598E-06 
— 1 . 824E-06 
—2 , 005E-06 
—2 . 138E-06 
—2 . 278E-06 
-2.418E-06 
0.000E+00 
3 . 595E-07 
9.837E-07 
1.334E-06 
1.598E-06 
1 . 824E-06 
2 . 005E-06 
2.138E-06 
2.278E-06 
2.418E-06 
0.000E+00 
3 . 595E-07 
9 . 837E-07 
1 . 334E-06 
1.598E-06 
1.824E-06 
2 . 005E-06 
2 . 138E-06 
2 . 278E-06 
2 . 418E-06 
0.000E+00 
—3 . 595E-07 
-9 . 837E-07 
-1 . 334E-06 
-1 . 598E-06 
-1 . 824E-06 
-2 . 005E-06 
-2 . 138E-06 
-2 .278E-06 
-2.418E-06 
2 . 226E-19 
2.091E-19 
1 . 965E-19 
3 . 993E-19 
3 . 611E-19 
4.297E-19 
1.680E-18 
1.684E-18 
1.518E-18 


Rx 

O.OOOE+OO 
2 . 051E—Q7 
4 . 102E—07 
5 . 387E-07 
6.199E-07 
7 . 010E-07 
7 . 822E-07 
8 . 634E-07 
8 . 634E-07 
8 . 634E-07 
O.OOOE+OO 
-2.051E-07 
-4 . 102E-07 
-5.387E-07 
-6.199E-07 
-7.010E-07 
-7.822E-07 
-8 . 634E-07 
-8.634E-07 
-8 . 634E-07 
O.OOOE+OO 
2.051E-07 
4 . 102E-07 
5 . 387E-07 
6 . 199E-07 
7 . 010E-07 
7.822E-07 
8 . 634E-07 
8.634E-07 
8.634E-07 
O.OOOE+OO 
-2 . 051E—07 
-4.102E-07 
—5 . 387E-07 
—6 . 199E-07 
-7.010E-07 
-7.822E-07 
-8.634E-07 
-8 . 634E-07 
“8 . 634E-07 
6.502E-06 
-1 . 787E-16 
-6.502E-06 
8 . 829E-06 
-3 . 545E-16 
—8 . 829E-06 
1.414E-05 
—1 . 451E-15 
-1 . 414E-05 


Ry 

O.OOOE+OO 
8 . 649E-0  6 
7.563E-06 
4 . 677E-0  6 
4 . 093E-06 
3 . 412E-G6 
2 . 632E-06 
1.754E-06 
1.754E-06 
1.754E-06 
O.OOOE+OO 
-8.649E-06 
-7.563E-06 
—4 . 677E-0  6 
-4.093E-06 
-3.412E-06 
-2.632E-06 
— 1 . 754E-06 
-1.754E-06 
-1.754E-06 
O.OOOE+OO 
-8.649E-06 
—7 . 563E-06 
—4 . 677E-06 
-4 . 093E-06 
—3 . 412E-06 
-2.632E-06 
— 1 . 754E-06 
—1 . 754E—06 
— 1 . 754E— 06 
O.OOOE+OO 
8. 649E-06 
7.563E-06 
4 . 677E-06 
4 . 093E-06 
3 . 412E-0  6 
2 . 632E-06 
1.754E-06 
1.754E-06 
1 . 754E-06 
-2 . 774E-18 
-2.243E-19 
-3.143E-18 
-3.473E-18 
-2.268E-19 
—4 . 018E-18 
-4 . 718E-18 
-2 . 816E-19 
—5 . 687E-18 


Rz 

O.OOOE+OO 
1 . 248E-03 
2.148E-03 
2.685E-03 
3 . 079E-03 
3.359E-03 
3 . 526E-03 
3 . 582E-03 
3 . 59QE-03 
3 . 592E-03 
O.OOOE+OO 
1 . 248E-03 
2.148E-03 
2 . 685E-03 
3.079E-03 
3 . 359E-03 
3 . 526E-03 
3.582E-03 
3 . 590E-03 
3 . 592E-03 
O.OOOE+OO 
1 . 248E-03 
2 . 148E-03 
2 . 685E-03 
3 . 079E-03 
3 . 359E-03 
3 . 526E-03 
3 . 582E-03 
3 . 590E-03 
3 . 592E-03 
O.OOOE+OO 
1.248E-03 
2.148E-03 
2 . 685E-03 
3 . 079E-03 
3 . 359E-03 
3 . 526E-03 
3.582E-03 
3.590E-03 
3 . 592E-03 
-1.074E-03 
-9.06GE-04 
-1.074E-03 
-1 . 342E-03 
-1 . 131E-03 
-1 . 342E-03 
-I . 791E-03 
— 1 . 507E-03 
-1.791E-03 
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Appendix  M.  Final  Controller  Design 

M.l  Overview 

This  appendix  contains  the  controller  gains  and  Matlab  output  graphs  for  various 
maneuvers  of  the  baseline  SIMS  A  T  design  shown  in  Figure  5.24.  These  maneuvers  are  NOT 
performed  sequentially;  the  SIMS  AT  state  vector  is  set  to  zero  before  each  maneuver. 


M.2  Gain  Settings  Development 

The  following  pages  list  the  input  gain  matrices  used  in  the  final  controller  design. 
For  each  set  of  input  gains,  system  output  performance  is  illustrated  using  the  MATLAB 
simulation  graphs.  Successive  iterations  were  used  to  determine  gain  sets  to  accomodate 
the  various  SIMS  A  Toperating  modes.  These  gains  can  be  adjusted  by  the  user  in  actual 
system  operation  as  necessary. 
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Table  M.l  Options  1  and  2  -  Gains 


Final  Closed-Loop  Controller  Design 


|Option#1  (Target  Mode)  "1 


Manvr  # 

Command 

(degrees) 

Gain  Matrix 

K, 

Gain  Matrix 

k2 

Gain  Matrix 

k4 

1 

Roll  = 

0 

1000 

0 

0 

-10 

0 

0 

1 

0 

0 

Yaw  = 

90 

0 

350 

0 

0 

-50 

0 

0 

1 

0 

Pitch  = 

0 

0 

0 

1000 

0 

0 

-10 

0 

0 

1 

2 

Roll  = 

0 

0 

-10 

0 

0 

1 

0 

0 

Yaw  = 

0 

0 

500 

0 

0 

-50 

0 

0 

1 

0 

Pitch  = 

0 

0 

0 

0 

0 

0 

0 

1 

3 

Roll  = 

0 

1000 

0 

0 

-10 

0 

0 

1 

0 

0 

Yaw  = 

0 

0 

1000 

0 

0 

-50 

0 

0 

1 

0 

Pitch  = 

20 

0 

0 

600 

0 

0 

-10 

0 

0 

1 

4 

Roll  = 

-30 

100 

0 

0 

-50 

0 

0 

1 

0 

0 

Yaw  = 

-50 

0 

400 

0 

0 

-50 

0 

0 

1 

0 

Pitch  = 

-10 

0 

0 

1000 

0 

0 

-10 

0 

0 

1 

5 

Roll  - 

30 

100 

0 

0 

-50 

0 

0 

1 

0 

0 

Yaw  = 

50 

0 

400 

0 

0 

-50 

0 

0 

1 

0 

Pitch  = 

10 

0 

0 

1000 

0 

0 

mUM* 

0 

0 

1 

|Option  #2  (Target  Mode  with  Roll  Rate)  ~1 


Manvr  # 

Command 

(RPM/degrees) 

Gain  Matrix 

Ki 

Gain  Matrix 

k2 

Gain  Matrix 

k4 

1 

RollRate  = 

1 

0 

0 

0 

1 

0 

0 

20000 

0 

0 

Yaw  = 

10 

0 

1500 

0 

0 

-50 

0 

0 

1 

0 

Pitch  st 

-5 

0 

0 

1500 

0 

0 

-10 

0 

0 

1 

2 

RollRate  = 

9 

0 

0 

0 

1 

0 

0 

40 

0 

0 

Yaw  = 

30 

0 

500 

0 

0 

-50 

0 

0 

1 

0 

Pitch  = 

5 

0 

0 

1500 

0 

0 

-10 

0 

0 

1 

K3  =  0.0585 

Note:  1  RPM  =  6  deg/sec 
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Table  M.2  Options  3  and  4  -  Gains 


Final  Closed-Loop  Controller  Design 


jOption  #3  (Roll  Spin  Mode)  | 


Manvr  # 

Command 

(RPM) 

Gain  Matrix 

K, 

Gain  Matrix 

k2 

Gain  Matrix 

K4 

1 

RollRate  =  12 

0 

0 

0 

1 

0 

0 

30000 

0 

0 

0 

1500 

0 

0 

-50 

0 

0 

1 

0 

0 

0 

1500 

0 

0 

-10 

0 

0 

1 

2 

Roll  Rate  =  1 

0 

0 

0 

1 

0 

0 

30000 

0 

0 

0 

1500 

0 

0 

-50 

0 

0 

1 

0 

0 

0 

1500 

0 

0 

-10 

0 

0 

1 

3 

RollRate  =  -5 

0 

0 

0 

1 

0 

0 

30000 

0 

0 

0 

1500 

0 

0 

-50 

0 

0 

1 

0 

0 

0 

1500 

0 

0 

-10 

0 

0 

1 

[Option  #4  (Yaw  Spin  Mode) 


Manvr  # 

Command 

(RPM) 

Gain  Matrix 

K, 

Gain  Matrix 

k2 

Gain  Matrix 

k4 

1 

YawRate=  1 

2000 

0 

0 

-50 

0 

0 

1 

0 

0 

0 

0 

0 

0 

1 

0 

0 

200000 

0 

0 

0 

1000 

0 

0 

-10 

0 

0 

1 

2 

YawRate=  -1 

2000 

0 

0 

-50 

0 

0 

1 

0 

0 

0 

0 

0 

0 

1 

0 

0 

200000 

0 

0 

0 

1000 

0 

0 

-10 

0 

0 

1 

K3  =  0.0585 

Note:  1  RPM  =  6  deg/sec 
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Roll(solid),  Yaw(dashed),  and  Pitch(dotted)  Simsat  rollrate(solid),  yawrate(dashed),  pitchrate(dotted) 
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Figure  M.l  Option  1  (Target  Mode)  -  Maneuver 


Roll(solid),  Yaw(dashed),  and  Pitch(dotted)  Simsat  rollrate(solid),  yawrate(dashed),  pitchrate(dotted) 
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Figure  M.2  Option  1  (Target  Mode)  -  Maneuver 


Roll(solid),  Yaw(dashed),  and  Pitch(dotted)  Simsat  rollrate(solid),  yawrate(dashed),  pitchrate(dotted) 
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Figure  M.3  Option  1  (Target  Mode)  -  Maneuver  3 


Roll(solid),  Yaw(dashed),  and  Pitch(dotted)  Simsat  rollrate(solid),  yawrate(dashed),  pitchrate(dotted) 
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Figure  M.4  Option  1  (Target  Mode)  -  Maneuver  4 


Roll(solid),  Yaw(dashed),  and  Pitch(dotted)  Simsat  rollrate(solid),  yawrate(dashed),  pitch rate(dotted) 
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Figure  M.5  Option  1  (Target  Mode)  -  Maneuver  5 


Roll(solid),  Yaw(dashed),  and  Pitch(dotted)  Simsat  rollrate(solid),  yawrate(dashed),  pitchrate(dotted) 


Figure  M.6  Option  2  (Target  Mode  with  Roll  Rate)  -  Maneuver 


Roil(solid),  Yaw(dashed),  and  Pitch(dotted)  Simsat  rollrate(solid),  yawrate(dashed),  pitchrate(dotted) 


Figure  M.7  Option  2  (Target  Mode  with  Roll  Rate)  -  Maneuver  2 


Roll(solid),  Yaw(dashed),  and  Pitch(dotted)  Simsat  rollrate(solid),  yawrate(dashed),  pitchrate(dotted) 


Figure  M.9  Option  3  (Roll  Spin  Mode)  -  Maneuver  2 


Roll(solid),  Yaw(dashed),  and  Pitch(dotted)  Simsat  rollrate(solid),  yawrate(dashed),  pitchrate(dotted) 


Figure  M.10  Option  3  (Roll  Spin  Mode)  -  Maneuver  3 


Roll(solid),  Yaw(dashed),  and  Pitch(dotted)  Simsat  rollrate(solid),  yawrate(dashed),  pitchrate(dotted) 


Figure  M.ll  Option  4  (Yaw  Spin  Mode)  -  Maneuver  1 


Roll(solid),  Yaw(dashed),  and  Pitch(dotted)  Simsat  rollrate(solid),  yawrate(dashed),  pitchrate(dotted) 


Figure  M.12  Option  4  (Yaw  Spin  Mode)  -  Maneuver  2 
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